Tag: rhel

  • RHEL – Managing Passwords with Chage

    Large_SkeletonKeyPTo understand the chage command  if might be best to make sure that you understand the /etc/shadow file, so lets look at a line from mine. Note that “:” is the field separator.

    chris:$6$MZsU1MdDNVs50KaP$.sPNd90oOieOHAMwWt5rVB1:15188:0:99999:7:::

    In the shadow file the fields are as follows:

    1. Username
    2. Password Hash
    3. Date of Last Password Change in days since the dawn of Unix Time
    4. Minimum Password Age
    5. Maximum Password Age
    6. Password Warning Period
    7. Password Inactive Period
    8. Account Expiration

    The basic options of the chage command are as follows

    • -M Max Days
    • -m Min Days
    • -I inactive
    • -E Expiry Date
    • -D 0 Force Password Change

    So first lets take a look at the current settings for user “chris”. You will see that the entries below match the options listed above.

    # chage -l chris

    Last password change                                    : Aug 02, 2011
    Password expires                                        : never
    Password inactive                                       : never
    Account expires                                         : never
    Minimum number of days between password change          : 0
    Maximum number of days between password change          : 99999
    Number of days of warning before password expires       : 7

    So lets say that we want to force user chris to update his password on next login

    #chage -d 0 chris

    and then set a minimum number of days of 10 between password changes

    #chage -m 10 chris

    or set an expiration date of 10/10/2020

    #chage -E 10/10/2020 chris

    You get the idea…

    Anyway the chage command can be run interactively as well if you do not pass any options to the command other than the username.

    Additional Resources:

    Managing Password Aging on AIX, Solaris, Linux

    7 Examples to Manage Linux Password Expiration and Aging Using chage

  • RHEL- Find UUID of Hard Disks

    CinderblockAnyone who has added and removed multiple disks from a RedHat server knows very well that your disks may not always enumerate exactly the same way after a reboot. You then have to resort to mounting up your filesystems to a temporary mount point to see exactly whats in them, and were they really need to be mounted.

    Want to know if UUIDS are being used on your linux box, well just cat /etc/fstab, and if you see somthing similar to what’s below, then you are using UUIDS, instead of traditional disk device names.

    UUID=3fa4603e-9874-4f47-ae1c-3f7715a54238 /                       ext4    defaults,user_xattr        1 1
    UUID=483c34a4-b3ec-4860-854f-b9e5b6a6efac /boot                   ext4    defaults        1 2
    UUID=7cab6648-b3f3-4aaa-bb2b-d32b78156aab /var                    ext4    defaults        1 2
    UUID=7b05f0a9-18d5-42e5-b259-78ba3a8cc1b7 swap                    swap    defaults        0 0

    One way of mapping device UUIDS back to device names is the blkid command — usage and output below.

    [root@fedora15 ~]# blkid
    /dev/sda1: UUID=”483c34a4-b3ec-4860-854f-b9e5b6a6efac” TYPE=”ext4″
    /dev/sda2: LABEL=”_Fedora-15-x86_6″ UUID=”3fa4603e-9874-4f47-ae1c-3f7715a54238″ TYPE=”ext4″
    /dev/sda3: UUID=”7b05f0a9-18d5-42e5-b259-78ba3a8cc1b7″ TYPE=”swap”
    /dev/sdb1: UUID=”7cab6648-b3f3-4aaa-bb2b-d32b78156aab” TYPE=”ext4″
    /dev/sdb2: UUID=”rJfNaK-e3Xp-n3qm-4aXM-BfKF-g7sg-Kwm33a” TYPE=”LVM2_member”
    /dev/sdc1: LABEL=”raid1″ UUID=”34ed4ffd-cc4a-4b40-892f-6d7714fe7f4e” TYPE=”ext3″
    /dev/mapper/vm_vg-v1: UUID=”2d96aa43-b5b8-4185-8014-323ad8a07a0d” TYPE=”ext4″

    You can also do an ls on the following directory and get the same information.

    [root@fedora15 ~]# ls -l /dev/disk/by-uuid
    total 0
    lrwxrwxrwx 1 root root 10 Sep 25 21:41 2d96aa43-b5b8-4185-8014-323ad8a07a0d -> ../../dm-0
    lrwxrwxrwx 1 root root 10 Sep 25 20:51 34ed4ffd-cc4a-4b40-892f-6d7714fe7f4e -> ../../sdc1
    lrwxrwxrwx 1 root root 10 Sep 25 20:51 3fa4603e-9874-4f47-ae1c-3f7715a54238 -> ../../sda2
    lrwxrwxrwx 1 root root 10 Sep 25 20:51 483c34a4-b3ec-4860-854f-b9e5b6a6efac -> ../../sda1
    lrwxrwxrwx 1 root root 10 Sep 25 20:51 7b05f0a9-18d5-42e5-b259-78ba3a8cc1b7 -> ../../sda3
    lrwxrwxrwx 1 root root 10 Sep 25 20:51 7cab6648-b3f3-4aaa-bb2b-d32b78156aab -> ../../sdb1

    If you are so inclined, you can also get the UUID and filesystem label (if there is one) with the tune2fs command

    tune2fs -l /dev/sda1

    Filesystem volume name:   <none>
    Last mounted on:          /boot
    Filesystem UUID:          483c34a4-b3ec-4860-854f-b9e5b6a6efac
    Filesystem magic number:  0xEF53
    Filesystem revision #:    1 (dynamic)

    ….truncated…

    Oh and if you are running Fedora 15 and are wondering what the heck rootfs is (as I was), here is an explanation. More junk that I hope never gets into RHEL.

    Oh and if you are really bored, and would like to know more about what a UUID is go here

  • e1000 device eth4 does not seem to be present, delaying initialization

    0E4CEAFF-049A-4912-9057-6F3403FCB285-27600-0001E173F78AF5D7 The moral of the story today is beware of servers that have had a long history of changing networking configurations and network interfaces, as you never know what you are going to run into.

    While working on a RHEL 5.4 box and attempting to make few minor changes to eth4 and up the interface, I was smacked with the error below.

    e1000 device eth4 does not seem to be present, delaying initialization

    This was very much suck.

    Ifconfig-eth4 contained what you see below

    DEVICE=eth4
    BOOTPROTO=static
    ONBOOT=yes
    IPADDR=192.168.13.11
    NETMASK=255.255.255.0

    So first i hit up /etc/modprobe.conf and verifed that the correct driver module was being aliased for the interface.

    alias eth4 e1000

    Ok check. Modprobe.conf looks good.

    Now re-initialize driver

    modprobe eth100

    Then onto check lspci to make sure that the driver initialized all the interfaces. Note that there are two different versions of the 82546EB driver, which tells me that the driver was only initialized for two of the interfaces initially.

    2a:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
    2a:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
    2f:02.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
    2f:02.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)

    Turned my attention back to the ifconfig-eth4 and the fact that there was not a MAC address defined in the config file. Grabbed the mac address out of /etc/sysconfig/hwconf and added it to the ifconfig-eth4 config file

    class: NETWORK
    bus: PCI
    detached: 0
    device: eth4
    driver: e1000
    desc: "Intel Corporation 82546GB Gigabit Ethernet Controller"
    network.hwaddr: 00:04:23:cb:89:2e
    vendorId: 8086
    deviceId: 1079
    subVendorId: 8086
    subDeviceId: 1179
    pciType: 1
    pcidom:    0
    pcibus: 2f
    pcidev:  2
    pcifn:  0

    Then ifup works. Day is saved.

  • Meld — Graphical Merge and Diff Tool for Linux

    Mind-meldMeld is a very nice tool for those who cant stand to use diff to compare the differenced between two text files. If you have either the rpmforge repo or the epel repo configured you can install it via yum. Note: I am using Centos 5.4 which is a bit dated, so you might find a newer version in your repo depending on the OS that you are running.

    Anyway, once installed you can compare two files like so

    >meld syslog.conf syslog.conf.orig

    This  will pop up a side by side comparison of the two files in an Xwindow, so make sure that you have forwarding enabled. You might need to ssh -X to your server.

    Meld is not new by any means – the project's sourceforge page shows that its the latest meld version (1.5) was release. The version that I installed via my rpmforge repo is even older (1.1.5). Again I am running Centos 5.4.

    Meld can also be used to merge two files together and perform a diff on directory structures, however just having a nice looking diff is enough for me. 

    http://meld.sourceforge.net/

     

  • Linux Load Generating Script

    Daemon_hammer Nice little Linux load generating script courtesy of unixfoo.

    http://unixfoo.blogspot.com/2008/11/linux-cpu-hammer-script.html 

    More information on stress testing Linux can be found here

    There are also several additional stress test tools available for RHEL/CentOS in the Dag repo, such as stress, hammerhead,  and fio,

  • How to Configure NTP in a RHEL/CentOS Vmware Guest

    HourglassSuccessful time keeping in a Virtual Machine can be a bit confusing. At times I have been told to use Vmware Tools to sync time between the Guest and the Host, and at time I have been advised to avoid this functionality and use NTP. The following information is direct from a VMware KB article (updated, 4/16/2010) so I am going to follow their lead on this and use NTP exclusively.

    First off VMware advises using the NTP service to keep time in sync, but it suggests
    using an additional kernel parameter that you add to your grub.conf. See the KB Article for more info on how to do this.

    • notsc for RHEL/Centos 4.6 64bit
    • notsc divider=10 for  RHEL/Centos 5.3 64bit

    Note that there are no additional params needed for 5.4

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

    Also, inside the ntp.conf the following line should be added to the top of the file.

    tinker panic 0

    This configuration directive instructs NTP not to give up
    if it sees a large jump in time. This is important for coping with large
    time drifts and also resuming virtual machines from their suspended state.

    It is also important not to use the local clock as a time source, often
    referred to as the Undisciplined Local Clock. NTP has a tendency to fall
    back to this in preference to the remote servers when there is a large
    amount of time drift.

    An example of such a configuration is below. You should comment out both
    lines.

    server 127.127.1.0

    fudge 127.127.1.0 stratum 10

    Also, if you are using ntp, you want to make sure that you disable
    Vmware tools time sync. You can do so with the following command via the
    guest OS.

    vmware-guestd –cmd “vmx.set_option synctime 1 0”

  • Redhat I/O Scheduler Configuration in a Virtual Machine.

    Dali-melting-time-wall-clock The Linux kernel controls disk I/O scheduling, and is responsible for its optimization. One of the ways that it does this is via an I/O elevator to reorder and schedule pending I/O requests in order to minimize the time spent moving the
    disk head. This reduction in movement results in a reduction in disk seek time which in turn,  maximizes hard
    disk throughput.

    However, because of the fact that ESX is its own built in elevator, the Linux kernel’s elevator is not needed, and in fact can hurt disk performance. So its best to disable the elevator inside your linux VMs.

    One way to do this is to edit your /etc/grub.conf and add “elevator=noop” as seen below. This will require a reboot to take affect.

    title CentOS (2.6.18-53.el5)
            root (hd0,0)
            kernel /boot/vmlinuz-2.6.18-53.el5 ro root=LABEL=/ noapic acpi=off rhgb quiet notsc elevator=noop
            initrd /boot/initrd-2.6.18-53.el5.img

    To make the change on the fly to a running Linux VM run the command below, where device is your boot disk

    echo noop > /sys/block/DEVICE/queue/scheduler

    Additional Information:

    http://www.redhat.com/magazine/008jun05/features/schedulers/

    http://kbase.redhat.com/faq/docs/DOC-7539

    http://lonesysadmin.net/2008/02/21/elevatornoop/

    http://www.redhat.com/docs/wp/performancetuning/iotuning/iosubsystem-scheduler-selection.html

    http://www.linuxjournal.com/article/6931