Brian Smith's AIX / UNIX / Linux / Open Source blog
|Modified on by brian_s|
|Modified on by brian_s|
|Modified on by brian_s|
Often times you'll find a command line that works perfectly when you run it locally on a server, but doesn't work when you run it remotely over SSH. Usually the problem is related to double quotes, or backticks in the command. In this post, we will go over problems with double quotes, but the same issue would apply to command lines with backticks in them. In this example, we are running a command locally on an HMC:
If I decide to run this command over SSH (perhaps through a script), it won't work:
What's going on here? Well' the problem is the way the quote marks are processed by the shell running the SSH command. We can see what is happening by changing the "ssh" part of the command to "echo". This will show what the shell is doing to the quote marks:
So what we need to do is tweak our "echo" command line until we get what is echo'd back to the screen to match the originally run command that worked when run locally:
Now that command is echoing back the exact command that works locally, it should also work over SSH:
Another option would have been to use single quotes, however with single quotes you'll have problems if you are trying to use shell variables within the command line, which is very common when scripting something like this. This is why I prefer to use the double quotes and just escape them. Without variables, this command with single quotes will work as well:
I recently received an email from someone who said they needed to change the CPU Pool on hundreds of LPAR's and they asked if I had any suggestions to make the process easier.
There are a couple of ways this could be automated. One option might be to create a script that would generate the commands needed to make the change. But what I would probably do in this instance is just use a spreadsheet and a specially crafted formula to generate the command needed to make the change.
Basically, you create a spreadsheet with 3 columns:
Column A: LPAR Name
Column B: Frame Name
Column C: Desired CPU Pool
Column D: Our special formula to generate the commands
The formula in Column D needs to be something like this for Row 2 of the spreadsheet:
This formula builds the command line by pulling out the LPAR Name, Frame Name, and CPU Pool names out of columns A, B, C in Row 2 (Row 1 being a header).
You then go down to the bottom right of the formula cell, until your mouse turns in to a cross, then click and drag the formula down in to all of the cells below it in column D. Now you have your formula setup in Column D all the way down the spreadsheet, and you just need to fill in columns A, B, and C with your LPAR, Frame, and CPU Pool details. Then simply copy/paste the generated commands in to your HMC to make the changes.
The commands generated by the formulas look like the lines below. Basically it is the command to DLPAR change the CPU pool, followed by a command to force overwrite the current profile with the running configuration so that the CPU pool change gets updated in the profile as well:
IBM recently released a draft Redbook covering the upcoming HMC Version 8 Release 8.8.1.
I've read through the Redbook, and here are the no nonsense highlights I noticed:
POWER5 servers won't be supported in HMC Version 8
POWER6/POWER7/POWER8 servers will be supported. This one caught me by surprise and I am hoping that IBM will change this and end up supporting POWER5 on HMC Version 8 at some point in the future. If you have POWER5 servers still in your environment make sure you let IBM know that you want POWER5 support on HMC Version 8.
Your old HMC's might not be compatible with HMC Version 8
You need to have a Rack Mounted CR5 or later HMC or a Desktop C08 or later HMC with at least 2 GB of memory to run HMC Version 8. So this means people with 7042-CR4 HMC's or older will not be able to upgrade to HMC Version 8.
Running HMC Version 8 as a Virtual Machine still not supported
Totally absent from the Redbook draft is any mention of running HMC Version 8 as a Virtual Machine (under VMware for example). This is disappointing because with the short lived SDMC IBM supported running it in a virtual environment. Hopefully this will change and IBM will one day support running the HMC as a virtual machine.
New Performance and Capacity Monitor
A very cool new feature in HMC Version 8 is a integrated performance and capacity monitor. This will graph information about CPU usage, memory usage, network throughput, and storage throughput. It will support POWER6 and later servers. In previous HMC versions we had to use 3rd party software like LPAR2RRD for this kind of functionality. This is a very cool feature and I'm looking forward to trying it out.
Further SR-IOV Support
HMC Version 8 will add further support for virtualizing adapters with SR-IOV. This is similar in concept to the old IVE (Integrated Virtualized Ethernet) adapters in that it lets you take a single physical port and assign logical ports to multiple LPAR's. SR-IOV works independent from the VIO server and doesn't require a VIO server at all. You can create up to 48 logical ports per physical adapter. It is very fast, high performing and also supports QoS (quality of service). However the big drawback to SR-IOV is that it doesn't support Live Partition Mobility (LPM), suspend/resume, or remote restart. One possible way to get around this limitation is to assign a SR-IOV logical port to a VIO and create a SEA adapter out of it. But I'm not sure of a practical scenario in which someone would do that.
You might have a multiple step upgrade process to get to HMC 8
You can only upgrade to HMC Version 8 from 7.7.8 (with MH01402) or from 7.7.9. So if you are running a version older than this you'll need to do a multi-step upgrade and upgrade to one of these levels first, and then to HMC Version 8. Not a big deal, but something people need to be aware of so that they can get all the correct media needed for the upgrade and allocate enough time to do a multi-step upgrade.
Partition Remote Restart enhancement
Remote Restart is a very cool feature that allows LPAR's to automatically come back up on another frame in the event of an outage on the frame they were originally running on. This is super handy since you can't use LPM if the source server is down. Previously you could only enable Remote Restart on a LPAR at the time the LPAR was created. With HMC Version 8 this limitation has been removed and it can now be enabled without having to re-create the LPAR. Awesome!
Other Miscellaneous Improvements
Here are some other improvements
Post a comment if I missed any other big new features in HMC Version 8.
This post is about a script I wrote for building filesystems on AIX. It automates the process of creating logical volumes, filesystems, mounting them, setting user/group owners, and setting permissions. It can be used to create large numbers of filesystems quickly, and it is also handy if you need to create the same filesystems across multiple different servers.
Start by creating a CSV file based on this example/template (the first line is the header line). Simply copy and paste this in to a new file and name it with a .csv extension:
Open up this CSV file in your favorite spreadsheet application (I'm using LibreOffice in this example, but Excel should work as well). Once in the spreadsheet make changes to your CSV file specify what filesystems you want to create:
The columns are pretty self explanatory. The "Mount Options" is optional (and if you specify multiple mount options separate them with a period, i.e. rbrw.cio.dio) The "Log" is also optional (if you don't specify it will default to an existing log in the volume group).
Once you are done editing the file in the spreadsheet save it in CSV format. It MUST be CSV to work. To make sure, transfer the file to your AIX server and "cat" the file, and you should see something similar to this:
Now run the script and specify the CSV as a parameter. By default, the script doesn't make any changes or actually do anything at all other than show the commands that need to be run to create the filesystems:
Review the output to make sure everything looks good. If you want to actually run the commands generated, you can either redirect the output to a file and run that file as a script, or you can just run the scriptfs script and pipe it to "ksh" which will cause it to run the commands and actually create the filesystems:
When this ran, it created the logical volume, filesystem, mounts them, changes the user/group, and sets the permissions.
Here is the script:
I was asked about how to connect to a Power 5 server through a serial cable and made a quick video that shows what you need, and how to connect to the server and access the text based ASMI as well as boot in to SMS and then boot from a CD all through a serial cable using PuTTY.
This isn't the best quality video but I thought I would put it out here in case it can help someone else who is having problems accessing their server through a serial cable..
There are several storage related settings in AIX that cannot be changed if the device is active. These include "fast_fail" , Dynamic tracking (dyntrk), and the "num_cmd_elems" for HBA's and the Queue Depth for hdisks.
Your options to set these are either make the device inactive (usually by taking redundant paths offline) and then make the change, or to use the "-P" flag on chdev and then reboot the server to make the change effective at the next boot.
The "-P" option on chdev has one major drawback however. As soon as you make the change with chdev "-P" it appears that the setting is active right away even before the reboot. If you check with "lsattr" it will appear as if the setting has taken effect. However it actually won't take effect until the next reboot. What has essentially taken place is that the running configuration is out of sync with the ODM. The ODM reflects the updated settings, however they can't be changed in the running configuration of the AIX kernel until the next reboot.
Until recently, the only way to really verify if these kinds of attributes were actually active was to check in KDB. Last year I even wrote a script that would check this in KDB and report differences (see post: Script to show if your AIX HBA / hdisk settings are actually in effect )
Very recent versions of AIX have made a major improvement to "lsattr" where you now have a "-P" flag to show what is actually currently active. Chris Gibson did a very good write up on this on his blog (see his post: Thanks kdb but lsattr's got me covered! )
I wrote a script that will go through every device on your AIX server and compare the "lsattr -Pl" (running config) versus "lsattr -El" (ODM config) and show you all devices that have differences. If the script finds any differences it will show you which attributes are different between the ODM and the running configuration. If everything is in sync then there isn't any output.
Since the script relies on "lsattr -Pl" you must be at AIX 6.1 TL9 or AIX 7.1 TL3 or later for this script to work! If you are running an older AIX version check out my previous script that uses KDB (Script to show if your AIX HBA / hdisk settings are actually in effect)
Here is some example output from the script that shows fcs0's num_cmd_elems and hdisk0's queue_depth attributes are changed in the ODM but not on the running/active system. The ODM configuration for num_cmd_elems is 199 but the running configuration is 200. Likewise, the queue depth ODM configuration is 19 but the running configuration is 20.
Here is the script (again, note that it needs AIX 6.1 TL9 or AIX 7.1 TL3 or later to work):
I recently got an email from Dan Aldridge with some information about a very handy AIX command, "chdef". I wasn't familiar with this command before, and it is super-useful, so I thought I would write a quick post about it..
The HMC version 18.104.22.168 introduced a new "Current Config Sync" feature that is very, very useful.
Anyone who has been working with Power Systems for long has been bitten by the fact that LPAR's saved "Profiles" and their "Running Configs" can get out of sync. For example, if you DLPAR some new Virtual Adapters to your VIO server, and forget to add them to the profile as well, you might have serious issues the next time you shut down and reboot your VIO server. This is because anything in the "Running Config" is lost when the LPAR is shutdown if it wasn't also added to the persistent profile. For several years, anytime you did a DLPAR change (such as adding/removing Memory/CPU's/Virtual CPU's/Virtual Adapters/etc.) you had to also make the same change in the profile or else you would loose the change the next shutdown/re-activation. This was such a problem that I created a extensive script that reports differences between the running config and the profile (see prdiff website for more info: http://prdiff.sourceforge.net/ )
A few years ago IBM introduced a very cool HMC feature that allowed you to "Save the Current Configuration". This allowed you to take the "Running Config" and save it to the profile overwriting whatever was there. This allowed you to make your DLPAR changes, then just "Save Current Configuration" to write the changes you made to the profile. This was a good step in the right direction, but still left room for error. If you forgot to "Save Current Configuration" after making a DLPAR change you would still have problems the next time you shutdown/re-activated the LPAR.
There is now a new "Current Config Sync" feature in HMC 22.214.171.124. This new feature is awesome and what everyone has been asking IBM for since DLPAR was first introduced..
If enabled, the "Current Config Sync" feature will automatically "Save the Current Configuration" anytime you make a DLPAR change. You don't have to do anything extra.. You just make your DLPAR change and it will automatically be Sync'd with the profile. Awesome!
The first thing you need to do is enable the "Current Config Sync" option. This feature is disabled by default (more on this later in the post). Start by clicking on the LPAR's name in the HMC window to bring up the Partition Properties. Right at the bottom of the general tab you will have the following "Sync current config" options:
By default, it is set to "Sync turned OFF". Change this to "Sync turned ON". Once you do this and click OK, the HMC will go ahead and "Save the Current Configuration" of the LPAR to the profile.
Next, lets make a DLPAR addition of a Virtual SCSI adapter:
OK, so we've DLPAR'd in Virtual SCSI adapter #9 with a Client Adapter #9 as well. We have "Sync Turned ON", so when we check the profile we can see that this new VSCSI adapter was automatically added to the profile as well, without any further effort on our part:
The Third Option - Sync Suspended until next Activation
You can either have Sync turned "On", "Off", or "Suspended until next Activation". You might be wondering when you would choose this third option to suspend the sync? This option is useful if you need to make changes to the LPAR that are not possible to make through DLPAR. For example, if you needed to change the "Max CPU" setting, you can't change it through DLPAR. This is where the "Sync suspended until next activation" comes in handy!
Lets suppose we want to change the "Max CPU" setting for the "aix1" LPAR which currently has the Sync feature turned "On". We can't DLPAR this change, so we pull up the partition profile and change the Max CPU to 0.8:
When you click "OK" you will get this message:
This message is letting you know that by changing the LPAR's Profile like this you are going to cause the profile and running configuration to be out of sync, and that this will cause the Sync setting to be changed to "Sync suspended until next activation".
Here is a screenshot that shows they are now out of Sync:
So from this point the "Sync" is disabled since you have made a change that caused them to be out of sync. The next time you shutdown and re-activate the LPAR to activate your new Max CPU setting the "Sync" setting will automatically get changed back to "ON" and everything will be back in sync again:
One-Liner to Mass-Enable this Feature
The only downside to this feature is that it is disabled by default.. Using the GUI to enable it requires clicking on each LPAR one at a time and setting the Sync option to "On". If you have a bunch of LPAR's this would take forever!
Here is a one liner command to enable the Sync option on ALL LPAR's on the HMC:
Here is a command to check the status of the Sync option for all LPAR's:
It will show a "0" for "OFF", "1" for "ON", and "2" for "Sync suspending until next activation".
All I can say is "Well done IBM!" This is one of the most useful features added to the HMC in a very long time! If you haven't already, upgrade to HMC 126.96.36.199 and give this new feature a try.
I highly recommend only using scalable volume groups if at all possible.. But there are a lot of "Original" and "Big" AIX volume groups in existence out there, and you need to understand the relationship between Factor Size, Volume Group Type, and PP Sizes in order to support these volume groups.
Here is a table that shows for both Original and Big volume groups how changing the "Factor Size" changes the ratio between how many disks (PV's) the volume group can contain and how big they are. Basically you can either have lots of smaller disks, or fewer larger disks depending on how you set the Factor Size. The PP Size comes in to play because the larger the PP size the larger a disk the volume group will be able to support.
Original volume groups support a Factor Size between 1 to 16, and Big Volume groups support a Factor size between 1 to 64 (Scalable volume groups don't support/need a Factor Size)
For a script to show volume group details such as your current Factor Size and volume group type, see my previous post Deciphering AIX Volume Group limitations and types
Here are the tables that show all this in detail:
Original Volume Groups
Big Volume Groups
Mainly for my future reference, here is the script that generated these tables (written/ran on Linux with Bash, probably won't run on AIX without installing some GNU tools):
The man page for the AIX mkvg command states this about how Physical Partition sizes are determined for volume groups when they are created:
The default value for PP size is kind of hard to understand based on the man page description. Below are a couple of tables that show given a hdisk size what the default PP size would be if a volume group was created on it without specifying a PP size.
AIX basically defaults to the smallest PP size possible for the given disk, which is almost certainly not what you want. Especially with original and big volume groups a small PP size puts severe limitations on the total capacity of the PV and volume group.
I recommend using scalable volume groups, and specifying a PP size rather than just taking the default value. Think about what the requirements will be in the future, and pick a PP size for the volume group based on that. Remember that the PP size determines the increments that you will be able to add space to filesystems to, so don't pick too large of a PP size. For example, if you pick a 1 GB (1024 MB) PP size, and have a 4 GB filesystem and you need to add 0.5 GB to, you will be forced to add a full 1 GB since that is the PP size and you would have to add a entire PP. If the PP size had been 512 MB you would have been able to add just 0.5 GB rather than being forced to add a full GB.
To allow the volume group to have the maximum overall capacity in the future for growth, pick the largest PP size that would work for your current and future requirements. 128 MB, 256 MB, and 512 MB PP sizes are good middle ground sizes that will work in most circumstances (again, pick the largest that will work for your environment). Remember that you can not change a volume groups PP size after it is created without backing the data up and recreating it.
Here are the default PP sizes that AIX will default to if you don't specify the PP size yourself:
If you work with AIX systems that have original or big volume groups you are going to have limitations on the size of LUN's that can be supported by the volume group.
To find the maximum disk size allowed in the volume group, run "lsvg <vgname>". Find the "PP Size" and multiply it by the "MAX PPs Per PV". For example, if your PP size is 16 MB and your Max PPs Per PV is 2032 the maximum PV/disk size would be 32,512 MB (about 32 GB).
But what happens in this scenario if you take a 20 GB LUN and increase its size on the SAN to 300 GB? (way past the 32 GB limit of this particular volume group). AIX will not allow the LUN to increase in size when you run the "chvg -g" command, and the extra space will not be available to you. The extra space is allocated on the SAN but not usable on AIX so the space is essentially wasted.
Now, to fix this you have two options. Depending on the situation you might be able to change the volume groups "Factor Size" (see my previous post on Deciphering AIX Volume Group limitations and types) or you might have to convert to either a Big (usually no downtime) or Scalable volume group (requires volume group to be varried off). To convert to either Big or Scalable you must have free PP's on every PV/disk (see my previous post on a Script to free up PP's across all hdisks in an AIX volume group to make this process MUCH easier).
How can you tell if you have LUN's that are bigger than what the volume group supports? One of the easiest ways is to compare the output of what "lspv <hdisk>" reports for the total size of the disk against what "bootinfo -s" reports as the size of the disk. Normally there is a small discrepancy between these sizes because of the overhead that the volume group takes, but if there is a big discrepancy it means either the disk is to large for the volume group to support it, or you haven't run "chvg -g" yet for the volume group to recognize the increase size of the hdisk.
Here is a one liner script that will check all of the hdisks on a server. The first column of the output is the size of the disk that "lspv" reports. The second column is the size that "bootinfo -s" reports. The third column is the difference between these two numbers.
As you can see in this example, someone tried to resize hdisk5 to 300 GB, however this particular volume group only supports a max PV/hdisk size of 32 GB so the extra space cannot be utilized unless the volume group factor size is changed (which may or may not be possible) or unless the volume group is converted to a big or scalable volume group.
Often times System Administrators need to copy a file to remote servers with root authority. One example might be to push out an updated resolv.conf file to all servers. However, often times remote root logins are disabled so it can be difficult to copy files with root authority if root logins are disabled.
Here is a quick and easy method to copy files using root authority even if remote root logins are disabled. For this method to work, you will need the following setp:
Once this is done, you can use a combination of "cat", "sudo", and "ssh" to easily push out a file to mulitple servers with root authority..
Here is an example of pushing out a new resolv.conf file to all servers listed in the "serverlist" file:
It works by catting the file to be transferred and pipping it to the SSH connection. Within the SSH connection we sudo to root and then use cat to write the standard input to the file.
This will also work with binary files - not just text files..
I had a new article published on IBM developerWorks today: Getting started with Nmap for system administrators
The latest development versions of PuTTY have a awesome new feature called "Share SSH Connections" (Connection Sharing).
I did a video that covers the basics of this feature and shows a demo of it in action:
Calvin Powers recently interviewed me for the This Week on developerWorks Webcast regarding my recent developerWorks article on Tracing IBM AIX hdisks back to IBM System Storage SAN Volume Controller (SVC) volumes
See the interview over at the This Week on developerWorks Webcast blog.
Here is a quick one liner script you can copy/paste in to your HMC SSH terminal that will generate a HTML report showing all of the managed systems and LPAR's attached to the HMC and their current state.
You could easily change/extend the script to show other information like LPAR CPU settings, memory settings, etc. in the report as well.
This kind of script can be very handy to generate quick reports to send to people who might not have direct access to the HMC. You can also run the one liner on multiple HMC's, and combine the output in to a single HTML file to see information from all your HMC's in a single HTML report.
Here is the one liner script to run on the HMC to generate the report:
Here is sample output of what the generated HTML report looks like:
A couple of years ago I wrote a script to Trace Virtual SCSI / Shared Storage Pool Disks on AIX to VIO resources. This script automates the process of tracing back your VIO client VSCSI disks back to their VIO resources, and generates a nice HTML web report showing the details.
The original script is written to work in a HMC managed environment.
Steve Bromwich recently contacted me and let me know he had modified the original script to work in IVM environments such as those commonly found in Blade Center environments.
Here is the modified script for IVM use that Steve created: https://www.ibm.com/developerworks/community/blogs/brian/resource/vscsimap_ivm.zip
Steve said that you run the script from the IVM system. You need to have SSH keys setup to your AIX LPAR's that are on the IVM. Within the script you specify the name of the account that should be used (see the line that says "my $ivmuser = ". In addition, Steve also added in some code to show the name of the Volume Group for each client hdisk.
The Shell History file has saved my bacon many, many times. So many times I have used it to figure out what happened with a server after some kind of problem, or to find a command I had run before that I couldn't remember. The Shell history paints a very good picture of what has occurred on a server and is one of the first places I start when troubleshooting a server to see what has recently been happening.
It can also help document the configuration on a server. I remember many years ago we were having issues with a VIO SEA adapter and had to recreate it. Luckily we found the original command that was used to create the SEA in the history file so it was a piece of cake for us to recreate it.
By default the AIX history has a couple of limitations:
Many of these low limits we see today are archaic leftovers from a time long ago when computers had extremely limited resources. For example, one thing that drives me crazy is the default scroll back buffer of the popular PuTTY SSH client is only 200 lines! In an era of desktops with at least several Gigabytes of memory we certainly have room to store more than 200 measly lines of text! Luckily it is very easy to change the default scroll back buffer in PuTTY to something more reasonable like 10 million lines..
So in today's modern AIX environments where servers are often connected to terabytes of storage and often have hundreds of Gigabytes of RAM I think we have room to store a little more than 500 lines of shell history as well.
By default the AIX shell history file doesn't record the date/time stamp for each command that is run. This reduces the usefulness of the history file because the commands in it could have been run 10 minutes ago or 10 months ago, you just can't tell one way or the other. When troubleshooting an issue it can be extremely useful to be able to see that a command in the shell history was run at the same time a problem began.
Luckily it is extremely easy to fix both of these limitations with the default AIX Shell History. Simply add these lines to your global /etc/profile file:
These will increase the history size to 10,000 lines and record date/time stamps for each command run. Use the "-t" flag with the history command to see the date/time stamps next to each command.
Hopefully these simple tips will allow you to get more out of the AIX Shell History.
AIX stores the last time a user changed their password as a "epoch" time stamp, or in other words as the number of seconds since 1970.
For example, if you want to see when the last time root changed their password you can type:
This shows that root changed their password at 1,391,663,150 seconds after 1970. In other words, this really isn't very helpful unless you take this epoch number and convert it to a real date.
Here is a one liner function that will give you a "lastpwchg" command that will show a normal date/time for a users last password change. Just type "lastpwchg" followed by the username you would like to check:
The results look like this when you run it to check a user:
If you found this useful, you might also want to check out this post: Don't let your AIX passwords expire
Check out my latest article on Power IT Pro, "Compare Files Easily with the comm Command": http://poweritpro.com/system-admin/compare-files-easily-comm-command
Version 1.2 of EZH (Easy HMC Command Line Interface) has been released.
EZH is a script for the IBM HMC console to provide an alternate, easier to use, command line interface for many common commands and the goal of the project is to make the HMC command line interface easier to use for day to day administration tasks. It also includes an optional interactive menu to make it even easier to use.
EZH is Open Source and 100% free, and is very easy to install. For more information and to download, see the project page at http://ezh.sourceforge.net/
Last month an article I wrote on Tracing IBM AIX hdisks back to IBM System Storage SAN Volume Controller (SVC) volumes was published on IBM developerWorks.
The article included a script designed to automate the process of tracing back AIX hdisks back to SVC Volumes so that you could easily see all the SVC related information about the AIX hdisk, including the SVC volume name.
Dan Aldridge modified the script in the article with a few very nice improvements. It no longer depends on pcmpath, supports more versions of the SVC, and even works with SVC Volumes presented through Virtual SCSI (* Requires AIX 6.1 TL7 or later). For more information on what the script does and how to use it, see the original article linked above.
Here is the modified script from Dan:
Check out my latest article on Power IT Pro, "Boost Your Productivity with Single-Line AIX Shell Scripts": http://poweritpro.com/aix/boost-your-productivity-single-line-aix-shell-scripts
Being careful not to shoot yourself in the foot when cleaning up users and home directories on AIX and Linux
It is possible on Linux or AIX to have users that share a home directory. For example, you might have user1, user2, and user3 all have their home directories set to /sharedhome.
Anytime you are deleting users and home directories you need to keep this in mind. You might only need to delete "user1" but want to leave "user2" and "user3" unaffected. But if you delete user1 and its home directory you might end up deleting the shared home directory which would have a big impact on "user2" and "user3".
Let's look at this situation:
AIX and Red Hat both have a "userdel" command that will optionally erase the users home directory as well ("-r" flag).
On most versions of AIX, if you did a "userdel -r" on any one of the 3 users, it would deleted the /sharedhome directory which would impact the remaining 2 users that you didn't want to affect.
On Red Hat Linux, "userdel" tries to be smarter, and verifies that the owner of the home directory matches the user that is being deleted. Thus, if you did a "userdel -r user1" it would happily wipe out /sharedhome, but if you did a "userdel -r user2" or "userdel -r user3" it wouldn't delete /sharedhome because the owner of the directory doesn't match the user being deleted.
Here is a one-liner that will do a better job checking to see if a given directory is a shared home directory between multiple users:
Change "/sharedhome" to whatever directory you would like to check. If this comes back and says it is a shared home directory, then you need to do more research before attempting to delete the home directory.
So anytime you are cleaning up users and home directories, always keep in mind that users might have shared home directories and that under some circumstances AIX and Linux will wipe out these shared home directories which might affect other users on the system.
I've noticed that on some AIX servers there are these files:
These files are there on some servers, but not on others, so I was curious what their purpose was and what created them.
I started by googling the file names, and found a few references to them, but nothing that really explained why they are there or where they come from. So then I tried searching through all man pages with a command like this:
Based on this, it sounded to be like the files were a automatically generated backup file of these files.. The server I was working on didn't have a "/etc/opasswd", or "/etc/ogroup" files, so I tried creating a user, changing a users password, and deleting a user. After all this, the "/etc/opasswd" and "/etc/ogroup" files still didn't exist as I had expected them to....
Next, I decided to look through all the executables on the server and see which of them contained a reference to "/etc/opasswd":
# for dir in `echo $PATH | tr ":" " "`; do for file in `ls -1 $dir 2>/dev/null`; do [ -x $dir/$file ] && [ -f $dir/$file ] && strings $dir/$file | grep -q -i '/etc/opasswd' && echo "$file"; done; done
The only two executables found on the server with references to /etc/opasswd where "pwdck" and "usrck". I also ran "strings" on the libraries under /usr/lib but couldn't find any references to opasswd in them.
So I did some more experimenting and found that the "pwdck" and "usrck" commands do in fact make backup copies of files to /etc/opasswd, /etc/ogroup, /etc/security/opasswd, and /etc/security/ouser. These backup files could be used to help recover the system if pwdck or usrck messed something up on the system.. Mystery solved :)
Over the years I've noticed that a lot of the core utilities on AIX are actually shell scripts.
Here are some examples of these utilities on AIX that are either shell scripts (ksh/csh) or in some cases Perl scripts:
As you can see, there are some pretty important commands in this list. And this is just a small sample of them. On my AIX server I found that there are over 400 scripts included as part of base AIX! You can see a full list of all the scripts that make up your system by running a command like this:
It is pretty cool that so many of the core commands/utilities on AIX are made up of shell scripts. For one, it shows that shell scripts can take on very important and critical tasks. It can also be extremely helpful to be able to review the scripts if you are having any issues with any of these commands. And these scripts can be an excellent learning tool. These are extremely well written and robust scripts many of which have been used for decades on thousands and thousands of servers.
Installp is the main software packaging format used on AIX. When you install a installp fileset on an AIX server it installs files in to the appropriate directories on the AIX server. You can easily see a list of files that a installp package installed on the server by running "lslpp -f fileset" (where fileset is the name of any installed fileset).
When you install a installp fileset there is more going on then just files getting copied to the right place. Most filesets also include several scripts that are run when the software is installed or uninstalled. These scripts can do almost anything from stopping/starting processes, creating files, deleting files, changing configuration files or system settings, etc.
If you are having problems installing, upgrading, or uninstalling a installp fileset you might need to take a look at the filesets installp related scripts to troubleshoot the issue.
It is easy to extract these scripts following these steps. In this example, we are working with the SDDPCM fileset.
1. List the files in the fileset and look for the liblpp.a files:
The ./usr/lpp/devices.sddpcm.61/inst_root/liblpp.a file is for the root part of the install, and the ./usr/lpp/devices.sddpcm.61/liblpp.a is for the usr part of the install.
2. Extract the liblpp.a files:
The files are extracted relative to whatever directory you are currently in.
3. Extract the liblpp.a files:
The liblpp.a files contain the scripts, and can be extracted with the "ar" command:
The scripts have now all been extracted. The "config" and "unconfig" scripts are run at install time and uninstall time, respectively. There are also several other scripts that come in to play and a explaination of what each script does is available at: http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.genprogc%2Fdoc%2Fgenprogc%2Fpkging_sw4_install.htm