Managing puppet mount resources in AIX
Héctor Rivas Gándara
I am working on the mount provider for aix. I implemented it using the native commands from AIX to do so: crfs, rmfs, chfs, lsfs... In AIX the recomended and supported way to manage mount points is by using these commands, and not to modify the fstab equivalent, /etc/filesystems.
The problem that I have crfs (create) and rmfs (remove) do more than just create the needed entry in /etc/filesystems. If it is a local filesystem, the commands will create and format (jfs/jfs2) the needed Logical Volume, or directly remove the Logical Volume losing data.
So I am thinking that maybe is better create a provider that will modify directly /etc/filesystems, instead of use the standard AIX commands. That would keep consistent the behaviour of the provider between platforms (Linux, AIX, Solaris)... What do you think?
To manage Logical Volumes we can:
- Create a new type and provider for LVM... About this: any provider implementing LVM in other platforms? Any official plan? https://github.com/camptocamp/puppet-lvm ?
- Extend the mount type to add parameters to do so.
On the other hand, I didn't check it already, but: Can I implement a provider using Puppet::Provider::ParsedFile for a file with following syntax? Can you give me some clues to start it?
/usr:
dev = /dev/hd2
vfs = jfs2
log = /dev/hd8
mount = automatic
check = false
type = bootfs
vol = /usr
free = false
/var:
dev = /dev/hd9var
vfs = jfs2
log = /dev/hd8
mount = automatic
check = false
type = bootfs
vol = /var
free = false
Thx!
--
Atentamente
Héctor Rivas
Luke Kanies
Hello,
I am working on the mount provider for aix. I implemented it using the native commands from AIX to do so: crfs, rmfs, chfs, lsfs... In AIX the recomended and supported way to manage mount points is by using these commands, and not to modify the fstab equivalent, /etc/filesystems.
The problem that I have crfs (create) and rmfs (remove) do more than just create the needed entry in /etc/filesystems. If it is a local filesystem, the commands will create and format (jfs/jfs2) the needed Logical Volume, or directly remove the Logical Volume losing data.
So I am thinking that maybe is better create a provider that will modify directly /etc/filesystems, instead of use the standard AIX commands. That would keep consistent the behaviour of the provider between platforms (Linux, AIX, Solaris)... What do you think?
To manage Logical Volumes we can:
- Create a new type and provider for LVM... About this: any provider implementing LVM in other platforms? Any official plan? https://github.com/camptocamp/puppet-lvm ?
- Extend the mount type to add parameters to do so.
On the other hand, I didn't check it already, but: Can I implement a provider using Puppet::Provider::ParsedFile for a file with following syntax? Can you give me some clues to start it?
/usr:
dev = /dev/hd2
vfs = jfs2
log = /dev/hd8
mount = automatic
check = false
type = bootfs
vol = /usr
free = false
/var:
dev = /dev/hd9var
vfs = jfs2
log = /dev/hd8
mount = automatic
check = false
type = bootfs
vol = /var
free = false
Héctor Rivas Gándara
> So I am thinking that maybe is better create a provider that will modify directly /etc/filesystems, instead of use the standard AIX commands. That would keep consistent the behaviour of the provider between platforms (Linux, AIX, Solaris)... What do you think?
>
> Even though it results in inconsistent behavior between OSes, I'd prefer it be consistent with what people will expect on AIX than across OSes.
Ok, Maybe I can implement both behaviours. If user specifies the
Volume Group it will create the Logical Volume and the filesystems
using the 'crfs' command. If user specifies an existing and formated
Logical Volume (device), it can add the FS editing the file.
> Is there an option not to remove those FSes, but just to edit the files? That seems like a really dangerous action.
AFAIK, there is no option in command line tools. You have to edit the
/etc/filesystems.
And yes, it is really dangeous, in fact most commands in AIX are
pretty secure except this one, it deletes the data silently if he can
unmount the mountpoint.
> If your primary concern is in not losing data, then managing the files directly might be the best option after all.
At this moment what I did is not remove the FS unless the user set the
"options" parameter to "Yes, I am sure". Maybe we can add an extra
parameter to ensure that user really wants to lose the data.
> We have a largely supported module, on the company github site, I think, that manages lvm on Red Hat. I'd recommend using that as a starting point.
Great, I will use that.
> - Extend the mount type to add parameters to do so.
>
> This would probably be a good idea - preferably through resource generation, but maybe through direct action when possible, such as in this case.
Ok.
BTW, is there any way to extend an existing type using a module? Or
have I to modify the original type in puppet source (or rename it). I
tried to directly use the same filenames in the module, but it fails.
> /var:
> dev = /dev/hd9var
> vfs = jfs2
> log = /dev/hd8
> mount = automatic
> check = false
> type = bootfs
> vol = /var
> free = false
>
> Doesn't the existing mount provider basically do this? You should be able to pretty easily use it as a starting point, right?
Yes, but this is a stanza based file, each stanza has the format:
stanza-key:
property-key = property-value
property-key = property-value
property-key = property-value
Can parsefile manage that? If not, do you think it will be difficult
to extend it to manage these kind of files?
Just asking, I didn't check it, I will this week if I can.
--
Atentamente
Héctor Rivas
Luke Kanies
> On Sun, Dec 26, 2010 at 6:32 AM, Luke Kanies <lu...@puppetlabs.com> wrote:
>
>
>> So I am thinking that maybe is better create a provider that will modify directly /etc/filesystems, instead of use the standard AIX commands. That would keep consistent the behaviour of the provider between platforms (Linux, AIX, Solaris)... What do you think?
>>
>> Even though it results in inconsistent behavior between OSes, I'd prefer it be consistent with what people will expect on AIX than across OSes.
>
> Ok, Maybe I can implement both behaviours. If user specifies the
> Volume Group it will create the Logical Volume and the filesystems
> using the 'crfs' command. If user specifies an existing and formated
> Logical Volume (device), it can add the FS editing the file.
>
>
>> Is there an option not to remove those FSes, but just to edit the files? That seems like a really dangerous action.
>
> AFAIK, there is no option in command line tools. You have to edit the
> /etc/filesystems.
>
> And yes, it is really dangeous, in fact most commands in AIX are
> pretty secure except this one, it deletes the data silently if he can
> unmount the mountpoint.
:/
>> If your primary concern is in not losing data, then managing the files directly might be the best option after all.
>
> At this moment what I did is not remove the FS unless the user set the
> "options" parameter to "Yes, I am sure". Maybe we can add an extra
> parameter to ensure that user really wants to lose the data.
My temptation is to leave it off, but adding that option makes sense.
Sorry, I didn't understand your question the first time.
I think you can do it, but it might be a bit of a challenge because it's not terribly easy to parse - you'd be hard-pressed to write a regex that treats the whole thing as a single record. That being said, you could probably get close. You can do a regex to match the fs and all of the attributes, and then use an attached block to pull out the individual parameters.
--
All power corrupts, but we need the electricity.
-- Unknown
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
Héctor Rivas Gándara
>>> If your primary concern is in not losing data, then managing the files directly might be the best option after all.
>> At this moment what I did is not remove the FS unless the user set the
>> "options" parameter to "Yes, I am sure". Maybe we can add an extra
>> parameter to ensure that user really wants to lose the data.
>
> My temptation is to leave it off, but adding that option makes sense.
Actually I am now more likely to devel a provider that only modifies
the /etc/filesystems.
That will be a pretty much easier provider, since I will not have to
deal with command options and parse command outputs. For instance, the
"chfs" does not allow change several things, like remote server in NFS
mountpoints, device name...
On the other hand, I think that people using puppet on AIX probably
will have Linux aswell, I think it will be better keep consistence
between platforms.
> I think you can do it, but it might be a bit of a challenge because it's not terribly easy to parse - you'd be hard-pressed to write a regex that treats the whole thing as a single record. That being said, you could probably get close. You can do a regex to match the fs and all of the attributes, and then use an attached block to pull out the individual parameters.
Well, I will try these days to write it. On the other hand it will be
good example, a lot of configuration files have this format.
Thank you.
--
Atentamente
Héctor Rivas