Marc Grimme wrote:
>>> Hm. I like that awk, grep, etc are going with busybox on the one
>> hand.
>>> That would make things easier. I'll think about that.
>> OK. I'm more than happy to help with the testing/implementation of
>> this. As far as I can tell, all that would be required is creating the
>> symlinks - doable with something like:
>>
>> ./busybox --help |\
>> grep 'Currently defined functions:' -A30 \
>> | grep '^\s.*,' \
>> | tr , '\n' \
>> | xargs -n1 -i{} ln -s busybox {}
>>
>> (that's off the top of my head, don't quote me on it, and -A30 may be
>> too low)
>>
>> and pruning out the packages that are made redundant by it. If taking
>> it to the extreme and dropping bash as well, then all the shell scripts
>> would need to be checked to reference /bin/sh instead if /bin/bash,
>> and they'd need testing to make sure that they aren't broken by some bash
>> vs. sh obscurity.
> Right. But that's much work.
> There are many bash deps inside the code. I'm currently cleaning it
> up a little bit. But I don't see to get rid of bash in near time.
Are there really that many bash specific extensions in use in there that
aren't supported by vanilla bourne sh?
> As we are also going to support dracut as initrd for future clusters -
> on distros where it will be available (FC12, RHEL6, SLES???) - all this
> done there. They are using dash (posix shell). Currently we did not port
> the cluster filesystem parts but NFS to dracut.
Interesting. I didn't realize there was such a major change introduced
recently into the way initrd works.
> So bottomline is we'll stay with bash in bootscripts as it's too much
> work to move so far. Especially when I expect dracut to overpower our
> initrd.
Indeed, I see where you're going with this. It does sound like cometh
FC13/RHEL6 it may be time for a major change. And that puts a limit on
the life expectancy of the current setup. :-/
>>> BTW: I'm currently developing an initrd without the need of python
>> and
>>> friends. That will really spare a lot of space ;-) .
>> Now that IS interesting. What is python stuff actually used for? In
>> all my modding and patching of OSR I've never actually bumped into any
>> python code.
>
> com-queryclusterconf is python. And this queries the clusterconfiguration
> in a general way. This is required right now.
>
> AND most importantly for GFS clusters we need fenceagents in the initrd
> and most are based on python.
I've heard rumours to this extent, but all the ones I ever needed to use
were always written in perl.
> Although we could add those later on via bootsr.
Ouch. That's not ideal. Mind you, python vs. perl isn't that big a
difference in terms of disk footprint.
> But when we are getting rid of the com-queryclusterconf python dep we
> could build initrds without python/perl for NFS,OCFS2, glusterfs and localfs.
That is an interesting point. But doesn't OCFS2 need fencing agents? I
would expect it to, considering it is functionally nearly identical to
GFS. Speaking of which, I've been looking into getting Veritas Cluster
to work, and when I manage to get my hands on a trial licence I'll look
into adding support for it into OSR. ;)
Gordan
|
