If you want to remove an extra VMDK from a Linux VM,you need to follow these steps.
First you need to unmount the /dev/sdb1:
umount /dev/sdb1
Remove the /disk2 folder:
rmdir /disk2/
Remove the entry from the /etc/fstab:
nano or vi /etc/fstab
remove the following line:
/dev/sdb1 /disk2 ext2 defaults 1 2
Delete the device:
echo 1 > /sys/block/sdb1/device/delete
Remove the VMDK:
Samsungs TV's power cables are UL (Underwriters Labs) certified but are not CL (In-wall) rated. A CL rating on a cable (CL2 up to 150 volts, CL3 up to 300 volts) means these cables have a slow burning outer jacket that should meet the fire codes and are safe for in wall installations. Since the power cord for the TV is not CL rated it should never be installed inside a wall.
echo "- - -" > /sys/class/scsi_host/host#/scan
fdisk -l
tail -f /var/log/message
Create partition using fdisk and format it using mkfs.ext3 command:
# fdisk /dev/sdc
# mkfs.ext3 /dev/sdc3
# mkdir /disk3
Open /etc/fstab file, enter:
# vi /etc/fstab
Append as follows:
/dev/sdc3 /disk3 ext3 defaults 1 2
Save and close the file.
New-DatastoreByLun )
set-executionpolicy bypass
Profile.ps1 under %UserProfile%\Documents\WindowsPowerShell Microsoft.PowerShell_profile.ps1
Microsoft.PowerShellISE_profile.ps1
This is the daemon for the Advanced Configuration and Power Interface (ACPI). ACPI is an open industry standard for system control related actions, most notably plug-and-play hardware recognition and power management, such as startup and shutdown and putting systems into low poser consumption modes.
You'll probably never want to shut down this daemon, unless you are explicitly instructed to do so to debug a hardware problem.
Learn more:
http://www.acpi.info
One of the problems with living on a laptop, as so many of us do these days, is that when you set up a cron job to run, you can't always be sure that your laptop will be running at the time that the job should run. anacron (the name refers to its being an "anachronistic cron") gets around this problem by scheduling tasks in days. For example, anacron will run a job if the job has not been run in the specified number of days.
When are you safe not running anacron? When your system is running continuously. Should you simply stop cron from running if you have anacron running? No; anacron is able to specify job intervals in days, not hours and seconds.
Learn more:
http://anacron.sourceforge.net
This is the daemon for the Advanced Power Management (APM) BIOS driver. The APM hardware standard and apmd are being replaced by ACPI and acpid. If your hardware supports ACPI, then you don't need to run apmd.
This is the daemon for the at job processor (at enables you to run tasks at specified times). You can turn off this daemon if you don't use it.
This daemon automatically mounts disks and file systems that you define in a configuration file. Using this daemon can be more convenient that explicitly mounting removable disks.
Learn more:
http://freshmeat.net/projects/autofs
The Avahi website defines Avahi as: 'a system which facilitates service discovery on a local network. This means that you can plug your laptop or computer into a network and instantly be able to view other people who you can chat with, find printers to print to, or find files being shared…' Avahi is a Zeroconf implementation. Zeroconf is an approach that enables users to create usable IP networks without having special configuration servers such as DNS servers.
A common use of the avahi-daemon is with Rhythmbox, so you can see music that is made available to be shared with others. If you're not sharing music or files on your system, you can turn off this daemon.
Learn more:
http://avahi.org
http://zeroconf.org
more ...here...
You can use an override:
sudo echo "manual" >> /etc/init/lightdm.override To start lightdm on command:
sudo start lightdm To restore your system so that lightdm is always started on boot:
sudo rm /etc/init/lightdm.override For more information, the upstart cookbook is your friend:
Purpose
|
Description / Example
|
Install an RPM Package
|
RPM packages have file naming conventions like foo-2.0-4.i386.rpm, which include the package name (foo), version (2.0), release (4), and architecture (i386). Also notice that RPM understands FTP and HTTP protocols for installing and querying remote RPM files.
rpm -ivh foo-2.0-4.i386.rpm rpm -i ftp://ftp.redhat.com/pub/redhat/RPMS/foo-1.0-1.i386.rpm rpm -i http://oss.oracle.com/projects/firewire/dist/files/kernel-2.4.20-18.10.1.i686.rpm
|
Un-install an RPM Package
|
To un-install an RPM package, we use the package name foo, not the name of the original package file foo-2.0-4.i386.rpm above.
rpm -e foo
|
Upgrade an RPM Package
|
To upgrade an RPM package, RPM automatically un-installs the old version of the foo package and installs the new package. It is safe to always use rpm -Uvhto install and upgrade packages, since it works fine even when there are no previous versions of the package installed! Also notice that RPM understands FTP and HTTP protocols for upgrading from remote RPM files.
rpm -Uvh foo-1.0-2.i386.rpm rpm -Uvh ftp://ftp.redhat.com/pub/redhat/RPMS/foo-1.0-1.i386.rpm rpm -Uvh http://oss.oracle.com/projects/firewire/dist/files/kernel-2.4.20-18.10.1.i686.rpm
|
Query all Installed Packages
|
Use RPM to print the names of all installed packages installed on your Linux system.
rpm -qa
|
Query an RPM Package
|
Querying an RPM package will print the package name, version, and release number of the package foo only if it is installed. Use this command to verify that a package is or is not installed on your Linux system.
rpm -q foo
|
Display Package Information
|
RPM can display package information including the package name, version, and description of the installed program. Use this command to get detailed information about the installed package.
rpm -qi foo
|
List Files in Installed Package
|
The following command will list all of files in an installed RPM package. It works only when the package is already installed on your Linux system.
rpm -ql foo
|
Which package owns a file?
|
Use the following command to determine which installed package a particular file belongs to.
rpm -qf /usr/bin/mysql
For example:
# rpm -qf /usr/bin/mysql mysql-3.23.52-3
|
List Files in RPM File
|
Use RPM to query a (possibly) un-installed RPM file with the use of the the "-p" option. You can use the "-p" option to operate on an RPM file without actually installing anything. This command lists all files in an RPM file you have in the current directory. Also note that RPM can query remote files through the FTP and HTTP protocols.
rpm -qpl kernel-2.4.20-18.10.1.i686.rpm rpm -qpl ftp://ftp.redhat.com/pub/redhat/RPMS/foo-1.0-1.i386.rpm rpm -qpl http://oss.oracle.com/projects/firewire/dist/files/kernel-2.4.20-18.10.1.i686.rpm
|
Verify an Installed Package
|
Use RPM to list all files that do NOT pass the verify tests (done on size, MD5 signature, etc).
rpm --verify mysql
Where a file does NOT pass, the output is listed using the following codes that signify what failed:
S File size M Mode (includes permissions and file type) 5 MD5 sum L Symlink D Device U User G Group T Mtime
Take for example the following:
# rpm --verify mysql S.5....T c /etc/my.cnf
This example indicates that file /etc/my.cnf failed on:
File size MD5 Sum Modified Time
However, the "c" tells us this is a configuration file so that explains the changes. It should still be looked at to determine what the changes were.
|
Check an RPM Signature Package
|
RPM can be used to check the PGP signature of specified packages to ensure its integrity and origin. Always use this command first before installing a new RPM package on your system. Also, GnuPG or Pgp software must be already installed on your system before you can use this command.
rpm --checksig foo
|
<match target="font">
<edit mode="assign" name="autohint">
<bool>true</bool>
</edit>
</match>
The following code can serve as a template for creating a bash utility. The purpose of this wrapper utility is to checkout a file, edit in an editor and check the file back in.
The following is the command usage
root@host# ./rcwrapper [-c "comment goes here"] filename1 [filename2 filename3 ...]
#!/bin/bash
#########################
## Author: Nirav Doshi ##
## Date: Sept 25, 2012 ##
## Purpose:
## Facilitate checkout, edit
## and checkin process for code viewing,
## and editing.
#############################
export EDITOR=vim
while [ $# -gt 0 ]; do #until run out of parameters
case "$1" in
-c)
# Move the cursor to next argument which has comment information
shift
# set the comment value
if [ -n "$1" ] #compare if -c is passed with an argument
then
COMMENT=$1
echo "comment is \"$COMMENT\""
else
COMMENT="no comment supplied"
echo $COMMENT
fi
;;
*)
# Check out the file from repository
echo "CO -c \"$COMMENT\" $1"
# Calls the Editor program varriable along with filename
$EDITOR $1
# Checking file into the repository
echo "CI -c \"$COMMENT\" $1"
;;
esac
shift
done
yum or up2date to use. Then you can install packages with your usual method, and the EPEL repository is included. su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm' ... su -c 'yum install foo'For EL6:
su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm' ... su -c 'yum install foo'
http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
Place the script in /etc/rc.d/init.d and run (as root)
chmod +x /etc/rc.d/init.d/oracle
to make the script executable. If you are concerned about normal users seeing the script, you could try more restrictive file permissions, as long as the script is executable by root as a standalone script.
Notice the two comments lines in the script:
#chkconfig: 2345 80 05 #description: Oracle 8 Server
These lines are needed by chkconfig to determine how to establish the initial runlevels to add the service as well as set the priority for the start-and-stop script execution order. These lines denote the script will start Oracle 8 server for the runlevels 2, 3, 4 and 5. In addition, the start priority will be set to 80 while the stop priority will be 05.
Now that the script is in place with the appropriate execute permissions and the required chkconfig comments are in place, we can add the initscript to the chkconfig configuration by typing, as root, chkconfig --add oracle.
Using chkconfig's query feature, we can verify our addition:
[root]# chkconfig --list | grep oracle
Here are some important factors for using and developing naming conventions in a SAN:
Naming conventions
Use of descriptive naming conventions is one of the most important factors in
a successful SAN. Good naming standards will improve problem diagnostics,
reduce human error, allow for the creation of detailed documentation and
reduce the dependency on individuals.
Servers
Typically, servers will already have some form of naming standard in place.
The local server name is typically used as the host name defined to the disk
system. For the ESS you would normally use the server name in the server
description field. The same local server name can be used within the switch
fabric for zone settings, and whenever possible the use of the server name
should be consistent throughout the SAN.
Cabinets
SAN fabric cabinets should be labeled to adhere with local site standards.
SAN fabric components
A good naming convention for the SAN fabric component should be able to
tell you the physical location, component type, have a unique identifier and
give a description of what it connects to. The following are some descriptor
fields that may be considered when designing a fabric naming convention. If
your SAN only has one vendor type or only one cabinet, the name could be a
lot simpler.
Component description
This should describe the fabric component and the product vendor (for mixed
vendor environments) which will help you locate the management interface
and the component number within the SAN. For example, to give it a unique
identifier you may want to use something similar to the following:
Cpu(s): 11.4%us, 29.6%sy, 0.0%ni, 58.3%id, .7%wa, 0.0%hi, 0.0%si, 0.0%st
us: user CPU time. More often than not, when you have CPU-bound load, it's due to a process run by a user on the system, such as Apache, MySQL or maybe a shell script. If this percentage is high, a user process such as those is a likely cause of the load.
sy: system CPU time. The system CPU time is the percentage of the CPU tied up by kernel and other system processes. CPU-bound load should manifest either as a high percentage of user or high system CPU time.
id: CPU idle time. This is the percentage of the time that the CPU spends idle. The higher the number here the better! In fact, if you see really high CPU idle time, it's a good indication that any high load is not CPU-bound.
A little below it tells you which process is hogging the CPU usage. TOP by default sorts based on cpu usage so the high cpu consuming processes on top.
- wa: I/O wait. The I/O wait value tells the percentage of time the CPU is spending waiting on I/O (typically disk I/O). If you have high load and this value is high, it's likely the load is not CPU-bound but is due to either RAM issues or high disk I/O.
Mem: 1024176k total, 997408k used, 26768k free, 85520k buffers Swap: 1004052k total, 4360k used, 999692k free, 286040k cached
Ran into a bit of a problem initially installing 'puppet', the configuration management tool on RedHat. The installation was pretty straight forward, but if you are not using RedHat on a daily bases you may get thrown off.
I was aware enough to at least have EPEL installed on the system as indicated on EPEL article by Redhat folks
Install epel-release rpm package according to your RHEL version as shown below Links to these rpm packages can be found at http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F CommentThere are many packages included with Fedora that are not included in Red Hat Enterprise Linux. In effort to make certain, high quality packages from Fedora available for Red Hat Enterprise Linux, the Fedora community has created the Extra Packages for Enterprise Linux (EPEL) program. The EPEL program is a volunteer-run community program. New packages are suggested and added to the program by volunteers. Packages in the EPEL program are not supported by Red Hat. |
First of all, if you think you can kill Zombies; its ironic. Zombies are already dead. (Referring to processes)