Hello, I’ve got a bunch of AIX agents installed by default in a rootvg file system. The problem is that the default install location is small and managed to be small. How do I redirect all of BigFix’s local file stuff to a non-rootvg volume? Currently, what little patching content that is delivered for AIX is largely unusable because of the size of the packages. We can get around some of that with NFS mounts but still see a need to get the BigFix operations outside of our rootvg. We find that NFS has its own issues when you swamp it with a big patch push that hits it all at once too.
I understand that I may have to setup a vg and filesystem for BigFix to plunder and impact only itself. That said, how would I make the application know to route its stuff to a new location where it can play more nicely with the rest of the box?
You might be able to reinstall the client to a different location. I’m fairly certain you can do this on Windows, but I’m unsure how to do it on other OSes.
Symbolic links are the only supported way to install to a new location.
We only support the /var/opt/BESClient and /var/opt/BESRelay locations being redirected (its not good to break them up any more)
Stop the client (and or Relay) and move the files to where you want them to be then symlink the BESClient and/or BESRelay directories to the new locations.
Thanks guys. That seems like what I expected given the complete lack of instructions for customizing installation locations. I suppose this is a symptom of porting a Windows app over to AIX. Space and such are managed in much different manners. We’ll research whether we just want to grow rootvg or maybe link stuff off to an new vg.
Any opinions about maybe just making these locations their own independent file system to keep them from impacting /var. Maybe that leaves them where they are but isolates them better for space purposes?
I would think this would be a relatively common issue for AIX clients.
One last note, I believe my Linux guys have approached this problem with the NFS “solution”. Are you saying that their configuration is “not supported”?
As long as the path is still /var/opt/BESClient etc we don’t care what you make it
It does seem that /var is quite often a small partition. The locations we chose were a standard set of locations on UNIX (/opt and /var) for what we are using. An example of this is http://www.pathname.com/fhs/pub/fhs-2.3.html
We might have a gig of space there in many cases. Then BigFix comes along and wants to push 7GB upgrades into there to play. That doesn’t end with a smiley face. It is what it is. We’ve worked around this problem given that we have to code our own fixlets for AIX anyway. I’m having to address it now because we’re pondering adding Inventory and it appears that it will want to eat our puny /vars for sport. LOL. We actually had contracts with a disaster recovery vendor to limit our mksysb’s to 5GB. BigFix doesn’t play well on that mksysb so I need to get him his own bedroom.
FWIW,
I’ve got a rudimentary test going. Here’s what I’ve tried that appears to be working.
I shutdown the client.
I took a backup of the /var/opt/BESClient contents
I deleted the old /var/opt/BESClient and all contents for a cleanup.
I built a new logical volume and file system for /var/opt/BESClient
I restored the backup into the new file system.
I restarted the client.
Everything seems to be working.
I think I can script this up. However, given that I’m killing the client, I don’t know that I can push this change out with BigFix. Might just copy the move the file contents around instead of backup and restore too. I suppose I could have uninstalled the client and then reinstalled after the new filesystem was mounted.
This is a pain in the backside for us AIX customers. IBM might should think about providing different installation options.
You would have to create a script that does it all, then use the BigFix run command, which will start the script, but the client will move along without waiting. The script that is being run can shutdown the client, do all the things, and then bring the client back up.
You should definitely do careful testing for this.
What we do before the install is make a /var/opt/BESClient in another volume group and then do the install. In our case we can then control the size without affecting rootvg.
That actually sounds like a wise process to have followed. The trouble was that ours was installed with IBMs assistance and they don’t apparently think of such things and the documentation doesn’t provide any warnings of the space issues that become inevitable. So… no we get to figure out how to do it again and maybe do it “righter” this time.
