Here are ways to update the firmware on Dell iDRAC6 remote access cards.
Both methods require downloading the BIOS from Dell and extracting it
from the bundle. For example, this is the 1.70.21 firmware:
mkdir /tmp/dell
cd /tmp/dell
wget http://ftp.dell.com/esm/IDRAC6_FRMW_LX_R299265.BIN
Grab this and extract like this:
cd /tmp/dell
sh IDRAC6_FRMW_LX_R299265.BIN --extract ./idrac6-1.70.21
The firmware image is now in /tmp/dell/idrac6-1.70.21/payload/firmimg.d6
If using the CMC to update the firmware upload the extracted firmimg file, NOT THE BIN!
If you are just updating one machine, then the simplest way to perform the update is to use the Dell bmcfwul tool locally. This is supplied in the dell_ie_nitrogen package, and is installed to /usr/libexec/dell_dup/dell_ie_nitrogen/bmcfwul.
Install the new firmware like this:
/usr/libexec/dell_dup/dell_ie_nitrogen/bmcfwul -input=/tmp/dell/idrac6-1.70.21/payload/firmimg.d6
If you have several machines to update, the most convenient way to perform the update is with tftp.
First, copy the firmware image to the tftp server, and put it in /tftproot, or wherever the root of your tftp server is located:
scp /tmp/dell/idrac6-1.70.21/payload/firmimg.d6 $ip_of_tftp_server:/tftproot
Then, trigger a firmware upgrade on the machines remotely using either racadm or ssh:
racadm -r host.to.update -u root -p calvin fwupdate -g -u -a $ip_of_tftp_server
or
ssh host.to.update racadm fwupdate -g -u -a $ip_of_tftp_server
http://yo61.com/updating-dell-idrac6-firmware-linux.html
Monday, March 18, 2013
Saturday, December 29, 2012
More on Sticky bits and ACLs
I'm going through the tedious task of hardening our Linux servers for an upcoming FSO visit as well as tweaking our existing kickstart for future builds. A LOT of documentation goes into our kickstarts so we can pick things out and know what has been set and in response to which IAVA requirement. I wanted a really clear example on how to properly use sticky bits and setfacl so to apply appropriate permissions when new files are created within a directory. No point in setting the permissions on the current files if new ones can be created and bust the stig right?
The group ownership can be inherited by new files and folders created in your folder /path/to/parent by setting the setgid bit using
However, you can use POSIX ACLs to achieve this. Set the default ACL on a directory:
This will apply
(If needed, you can add a
Note that, at least with ext3/ext4, you must mount the filesystem with the
Edit
The group ownership can be inherited by new files and folders created in your folder /path/to/parent by setting the setgid bit using
chmod g+s like this:chmod g+s /path/to/parent
Now, all new files and folder created under /path/to/parent will have the same group assigned as is set on /path/to/parent.
POSIX file permissions are not inherited; they are given by the creating process and combined with its current umask value.However, you can use POSIX ACLs to achieve this. Set the default ACL on a directory:
setfacl -d -m u::rwX,g::rwX,o::- /path/to/parent
This will apply
setfacl to the /path/to/parent directory, -modifying the -default ACLs – those that will be applied to newly created items. (Uppercase X means only directories will receive the +x bit.)(If needed, you can add a
u:someuser:rwX or g:someuser:rwX – preferably a group – to the ACLs.)Note that, at least with ext3/ext4, you must mount the filesystem with the
acl option, otherwise new ACLs cannot be set and existing ones will be ignored. mount -o remount,acl /
Edit
/etc/fstab to set this permanently.
Saturday, November 24, 2012
Linux: sed command usage #1
I'm getting better with sed all the time but today was a challenging little booger. I wanted to change /etc/pam.d/su from
cat /etc/pam.d/su
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
to
cat /etc/pam.d/su
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
Notice the absense of the comment on line 6? If you used sed -i 's/\#auth/auth/' <file> it would only look at the first line and then quit. If you used sed -i 's/\#auth/auth/g' it'd change all of them. I wanted to change just ONE out of the whole file. The trick? To specify a LINE for sed to work on.
sed -i '6s/\#auth/auth/' /etc/pam.d/su
Finally! Looked for a while to find the answer. The key is using the line number at the beginning of the search string here. This link helped me get going in the right direction, http://www.linuxquestions.org/questions/linux-software-2/sed-display-text-on-specific-line-of-text-file-397405/. but it didn't give me EXACTLY what I wanted. However it helped me figure out how to specify a line. I knew I could do it after I was able to print the line I wanted to work on. SUCCESS!!
cat /etc/pam.d/su
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
to
cat /etc/pam.d/su
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so
Notice the absense of the comment on line 6? If you used sed -i 's/\#auth/auth/' <file> it would only look at the first line and then quit. If you used sed -i 's/\#auth/auth/g' it'd change all of them. I wanted to change just ONE out of the whole file. The trick? To specify a LINE for sed to work on.
sed -i '6s/\#auth/auth/' /etc/pam.d/su
Finally! Looked for a while to find the answer. The key is using the line number at the beginning of the search string here. This link helped me get going in the right direction, http://www.linuxquestions.org/questions/linux-software-2/sed-display-text-on-specific-line-of-text-file-397405/. but it didn't give me EXACTLY what I wanted. However it helped me figure out how to specify a line. I knew I could do it after I was able to print the line I wanted to work on. SUCCESS!!
Thursday, November 22, 2012
Need to make a Linux Kickstart iso?
I work with Linux on a daily basis. I'm also fortunate to have a good grasp on how to build servers and most of my co-workers, aside from a few, have trusted me to make most of the servers. It's a pain having to use a windows server just to mount the ISO to get the process started. Also if you're working from a longer distance away the size of that ISO burdens your connection. Behold the necessary steps to make a tiny ISO of just what you need to get the process started!
http://mikent.wordpress.com/2012/04/12/how-to-create-a-kickstart-iso-boot-disk-for-redhat/
2) create a directory name bootdisk/RHEL
mkdir -p bootdisk/RHEL
3) copy the directory isolinux from your RedHat DVD or other location containing RedHat binaries in bootdisk/RHEL
example: cp -R /mnt/isolinux/* ~/bootdisk/RHEL/
4) change direcotry to ~/bootdisk/RHEL/
cd ~/bootdisk/RHEL/
5) create (or copy) your ks.cfg (it will be discussed later in another post how to create a kickstart file) in ~/bootdisk/RHEL/
example: cp ks.cfg ~/bootdisk/RHEL/
6) Now, you can create the ISO boot disk as follow (make sure you run the command from ~/bootdisk/RHEL/) :
mkisofs -r -T -J -V “RedHat KSBoot” -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -v -o linuxboot.iso .
7) Burn your iso linuxboot.iso into a blank cd-rom or mount it as it is on a Virtual Machine for example
8) At linux boot prompt, type the following command:
linux ks=cdrom:/ks.cfg
if you need to install using a specific IP address using a specific Ks boot device, type the following:
linux ks=cdrom:/ks.cfg append ip=<IPaddress> netmask=<netmask> ksdevice=<NICx>
example: linux ks=cdrom:/ks.cfg append ip=10.10.10.10 netmask=255.255.255.0 ksdevice=eth0
9) your are done!
http://mikent.wordpress.com/2012/04/12/how-to-create-a-kickstart-iso-boot-disk-for-redhat/
How to create a kickstart ISO boot disk for RedHat
2) create a directory name bootdisk/RHEL
mkdir -p bootdisk/RHEL
3) copy the directory isolinux from your RedHat DVD or other location containing RedHat binaries in bootdisk/RHEL
example: cp -R /mnt/isolinux/* ~/bootdisk/RHEL/
4) change direcotry to ~/bootdisk/RHEL/
cd ~/bootdisk/RHEL/
5) create (or copy) your ks.cfg (it will be discussed later in another post how to create a kickstart file) in ~/bootdisk/RHEL/
example: cp ks.cfg ~/bootdisk/RHEL/
6) Now, you can create the ISO boot disk as follow (make sure you run the command from ~/bootdisk/RHEL/) :
mkisofs -r -T -J -V “RedHat KSBoot” -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -v -o linuxboot.iso .
7) Burn your iso linuxboot.iso into a blank cd-rom or mount it as it is on a Virtual Machine for example
8) At linux boot prompt, type the following command:
linux ks=cdrom:/ks.cfg
if you need to install using a specific IP address using a specific Ks boot device, type the following:
linux ks=cdrom:/ks.cfg append ip=<IPaddress> netmask=<netmask> ksdevice=<NICx>
example: linux ks=cdrom:/ks.cfg append ip=10.10.10.10 netmask=255.255.255.0 ksdevice=eth0
9) your are done!
Sunday, October 28, 2012
Disabling Adobe Updates on a Mac
As a Mac admin I'm becoming increasingly aware of all the crap you have to do special to administer these things in an enterprise environment. It's not as easy as Active Directory is with GPOs but rather it's more linux like since it is a Unix OS based on BSD. I have some annoying updaters which try to update all the friggin time Adobe products. Finally found a site which tells me how to do it, Stop Adobe Update Manager Launching.
Now I just need to test it for deployment using either Workgroup Manager or ARD.
Here’s how to do it through the command line:
* Launch Terminal (located in /Applications/Utilities/)
* At the command prompt, paste this command exactly
* Hit return to execute the command and create the plist file
You can double-check that the file has been created by looking in ~/Library/Preferences/ for the file. Now, theoretically at least, Adobe Update Manager will not launch on Mac user login and system boot.
There is also the option of manually creating the plist file, either though a plist editor or if you’re familiar with plists just by using a text editor.
Again you need to create a file located at /Library/Preferences with the name com.adobe.AdobeUpdater.Admin.plist with a boolean set true to “Disable.Update”, as you can see in the screenshot below:
Now you should be able to reboot your Mac, logout of a user, and anything as usual, without the annoyance of Adobe Update Manager barging in on your computing session. Stopped in it’s tracks!
Now I just need to test it for deployment using either Workgroup Manager or ARD.
Disable Adobe Update Manager
You need to create a file called com.adobe.AdobeUpdater.Admin.plist in your ~/Library/Preferences/ which can be done in two different ways, through the Terminal with a defaults write command, or by manually creating the file with a text editor.Here’s how to do it through the command line:
* Launch Terminal (located in /Applications/Utilities/)
* At the command prompt, paste this command exactly
defaults write com.adobe.AdobeUpdater.Admin Disable.Update -bool yes* Hit return to execute the command and create the plist file
You can double-check that the file has been created by looking in ~/Library/Preferences/ for the file. Now, theoretically at least, Adobe Update Manager will not launch on Mac user login and system boot.
There is also the option of manually creating the plist file, either though a plist editor or if you’re familiar with plists just by using a text editor.
Again you need to create a file located at /Library/Preferences with the name com.adobe.AdobeUpdater.Admin.plist with a boolean set true to “Disable.Update”, as you can see in the screenshot below:
Now you should be able to reboot your Mac, logout of a user, and anything as usual, without the annoyance of Adobe Update Manager barging in on your computing session. Stopped in it’s tracks!
Tuesday, October 23, 2012
Hacking RPMs
Ever want to modify a file within an RPM but you don't have the spec file or possibly even the source rpm? Now you can! And I've done it successfully using the link included as a guide along with the man page.
http://magazine.redhat.com/2007/12/04/hacking-rpms-with-rpmrebuild/
It's ultra cool! I've successfully built a customized RPM build for a zabbix agent which has modifications allowing it to be used across ANY network you'd like to use including a modified .conf file :) Oh the joys of linux.
But rpmrebuild doesn’t stop there; you can also modify actual RPM packages without needing access to its SRPMS or even knowing much about SPEC files. Although this may not be recommended when dealing with core/base Linux system RPMS, it is incredibly useful for developers, release engineers, and system administrators who needs to create internal RPMs for their organizations.
For example, it is common practice for release engineers to have a “back out strategy” in case a release does not meet requirements during installation. With rpmrebuild, the version and release numbers of an RPM that may be replaced by a new one can be tweaked so that in case there is a failure and the ”back out” RPM is needed, the release engineers can simply install the back out RPMs over the new RPMs. Then the back out RPMs will have higher version and/or release numbers on them, so a tool like up2date or yum can automatically pick up on the changes.
Rpmrebuild is currently available for Fedora 7 and 8. To install:
To rebuild an installed package in your system into an RPM:
While rebuilding a package, rpmrebuild will let you know if files have been modified from their original state.
If they have, it will give you the option to continue or halt the rebuilding of the package, and it will ask you if you want to change the release number of the package.
Example:
My favorite feature of rpmrebuild is the ability to modify its spec file on the fly. By that I mean that you can actually edit the spec of an existing RPM without having to rebuild from source. Why is this useful? Well, you can modify RPM package requirements, change logs, descriptions, and other fields on the spec without having to go through the entire build process again. It can save you a lot of time if you are in the business of building RPMs and don’t necessarily use auto-builders like koji or buildbot.
Here how’s it done:
Notice that the httpd package went from release #7 to #99.
Not as recommended, but useful for your organization’s internal applications, you can modify the version number of an RPM as well:
This command will rebuild your RPM and produce some-package-1.3.1.0.1-99.noarch.rpm.
Some other things to keep in mind about rpmrebuild are:
1.Once an RPM is rebuilt, it will lose its original signature (if signed).
2.You need to be root to rebuild a package only if there are root-protected files in that package.
3.Rpmrebuild will respect your RPM “home” building location, so if you have .rpmmacros set up in your home dir, your rebuilt RPMs will show up there.
The authors of rpmrebuild, Eric Gerbier and Valery Reznic, point out that even though the newer versions of RPM have a repackage option, they still require the user to uninstall that package from their system, which sometimes is not necessarily easy because of the dependencies on that package.
If you want to rebuild an old RPM that is not easily available on the Internet anymore, or if you need to tweak packages for your organization’s internal releases, or even if all you want to do is study and learn a bit more about RPM packaging, rpmrebuild is a great tool to have.
http://magazine.redhat.com/2007/12/04/hacking-rpms-with-rpmrebuild/
It's ultra cool! I've successfully built a customized RPM build for a zabbix agent which has modifications allowing it to be used across ANY network you'd like to use including a modified .conf file :) Oh the joys of linux.
Hacking RPMs with rpmrebuild
by afsilva
A couple of months ago, I discovered a tool called rpmrebuild while searching for a way to reverse engineer the files installed on an older Fedora system back into its original RPM package. Rpmrebuild is able to reconstruct an RPM by looking up the information about it on the RPM database that is part of every RPM-based distribution like Fedora.But rpmrebuild doesn’t stop there; you can also modify actual RPM packages without needing access to its SRPMS or even knowing much about SPEC files. Although this may not be recommended when dealing with core/base Linux system RPMS, it is incredibly useful for developers, release engineers, and system administrators who needs to create internal RPMs for their organizations.
For example, it is common practice for release engineers to have a “back out strategy” in case a release does not meet requirements during installation. With rpmrebuild, the version and release numbers of an RPM that may be replaced by a new one can be tweaked so that in case there is a failure and the ”back out” RPM is needed, the release engineers can simply install the back out RPMs over the new RPMs. Then the back out RPMs will have higher version and/or release numbers on them, so a tool like up2date or yum can automatically pick up on the changes.
Rpmrebuild is currently available for Fedora 7 and 8. To install:
yum install rpmrebuild
To rebuild an installed package in your system into an RPM:
rpmrebuild packagename
While rebuilding a package, rpmrebuild will let you know if files have been modified from their original state.
If they have, it will give you the option to continue or halt the rebuilding of the package, and it will ask you if you want to change the release number of the package.
Example:
[root@dhcp227-94 SOURCES]# rpmrebuild httpd Processing files: httpd-2.2.3-7.el5 Wrote: /usr/src/redhat/RPMS/i386/httpd-2.2.3-7.el5.i386.rpm result: /usr/src/redhat/RPMS/i386/httpd-2.2.3-7.el5.i386.rpm
My favorite feature of rpmrebuild is the ability to modify its spec file on the fly. By that I mean that you can actually edit the spec of an existing RPM without having to rebuild from source. Why is this useful? Well, you can modify RPM package requirements, change logs, descriptions, and other fields on the spec without having to go through the entire build process again. It can save you a lot of time if you are in the business of building RPMs and don’t necessarily use auto-builders like koji or buildbot.
Here how’s it done:
rpmrebuild -e -p –no-test-install package.rpm
- -e tells rpmrebuild you want to edit the whole spec file
- -p is used because we are editing an actual RPM file
- –notest-install stops rpmrebuild from auto-testing your RPM, just in case you are building an RPM on a workstation that does not have all required RPMs for that package
[root@dhcp227-94 i386]# rpmrebuild --release=99 -p --notest-install httpd-2.2.3-7.el5.i386.rpm Processing files: httpd-2.2.3-99 Wrote: /usr/src/redhat/RPMS/i386/httpd-2.2.3-99.i386.rpm result: /usr/src/redhat/RPMS/i386/httpd-2.2.3-99.i386.rpm
Notice that the httpd package went from release #7 to #99.
Not as recommended, but useful for your organization’s internal applications, you can modify the version number of an RPM as well:
rpmrebuild --change-spec-preamble='sed -e "s/^Version:.*/Version:1\.3\.1\.0\.1/"' --release=99 -p –notest-install some-package-1.3.1-11.noarch.rpm
This command will rebuild your RPM and produce some-package-1.3.1.0.1-99.noarch.rpm.
Some other things to keep in mind about rpmrebuild are:
1.Once an RPM is rebuilt, it will lose its original signature (if signed).
2.You need to be root to rebuild a package only if there are root-protected files in that package.
3.Rpmrebuild will respect your RPM “home” building location, so if you have .rpmmacros set up in your home dir, your rebuilt RPMs will show up there.
The authors of rpmrebuild, Eric Gerbier and Valery Reznic, point out that even though the newer versions of RPM have a repackage option, they still require the user to uninstall that package from their system, which sometimes is not necessarily easy because of the dependencies on that package.
If you want to rebuild an old RPM that is not easily available on the Internet anymore, or if you need to tweak packages for your organization’s internal releases, or even if all you want to do is study and learn a bit more about RPM packaging, rpmrebuild is a great tool to have.
Monday, October 8, 2012
D-Link Business Switches and port trunking
Aggravating as all get out when a business product which is CAPABLE of doing normal network switching decides to do things differently. I can understand maybe Cisco doing this or Juniper because they have the clout to change things. But D-Link? Really guys, why must you try to change how port trunking or vlan tagging works?
I'm configuring the network at my school with vlans, and it works great on the wireless, but wired connections... SHEESH. Short of it all is I did it wrong the first time. Had to go find someone else asking the same question on D-Link's support documents to find the correct answer.
With these switches you have Untagged, Tagged, and Not a Member settings for each port.
"Not member": This port is not a member of the VLAN.
"Tagged": The packets have already a VLAN-tag, i.e. they are tagged by the network device connected to this port.
"Untagged": The packets at this port have no VLAN-tags, so the incoming packets are tagged by the switch and the outgoing packets are untagged by the switch.
Which means you have to instead select the port and REMOVE all the OTHER vlans from the port instead of just add the vlan to the port you wish it to be a member of. That's bass-ackwards. So for the rest of the day my network is not working the way it was designed to work and I have to go AFTER work to fix it. GRR!!!
For more context see here: VLANS - Tagged, untagged, what do they all mean?
I'm configuring the network at my school with vlans, and it works great on the wireless, but wired connections... SHEESH. Short of it all is I did it wrong the first time. Had to go find someone else asking the same question on D-Link's support documents to find the correct answer.
With these switches you have Untagged, Tagged, and Not a Member settings for each port.
"Not member": This port is not a member of the VLAN.
"Tagged": The packets have already a VLAN-tag, i.e. they are tagged by the network device connected to this port.
"Untagged": The packets at this port have no VLAN-tags, so the incoming packets are tagged by the switch and the outgoing packets are untagged by the switch.
Which means you have to instead select the port and REMOVE all the OTHER vlans from the port instead of just add the vlan to the port you wish it to be a member of. That's bass-ackwards. So for the rest of the day my network is not working the way it was designed to work and I have to go AFTER work to fix it. GRR!!!
For more context see here: VLANS - Tagged, untagged, what do they all mean?
Subscribe to:
Posts (Atom)