Moab is the commercial HPC-scheduler offered by Cluster Resources (the same people who release Maui). This package does require a new license, and has fetch restriction set. When dealing with a larger site, Moab has a number of enhacements over Maui. Tested and being used on ppc64 and ppc. I'll check on x86 and amd64 soon.
Created attachment 123321 [details] moab-5.1.0_p5.ebuild
Created attachment 123323 [details] moab-init.d
Created attachment 123325 [details] 25moab (env.d)
Overall looks good. Small issues and nitpicks: ebuild: myconf="--with-key=$(cat /var/spool/moab/.moab.key)" You should use paths relative to ${ROOT} in cases like these. Also use $(< rather than $(cat init script: Your stop() function always returns success. Can you adapt it to use s-s-d? env.d file: can you explain why this is needed, and what effect it has?
(In reply to comment #4) > You should use paths relative to ${ROOT} in cases like these. Also use $(< > rather than $(cat Will fix that, thanks. > init script: > > Your stop() function always returns success. Can you adapt it to use s-s-d? If mschedctl fails, it doesn't return 1, and this is the preferred way to shutdown moab. Should I add start-stop-daemon if the mschedctl command fails? > env.d file: > > can you explain why this is needed, and what effect it has? Moab stores it's configuration files in /var/spool/moab rather than /etc. I basically emulated the Torque ebuild, as Torque behaves the same way. Is this unecessary?
Created attachment 123400 [details] moab-5.1.0_p5.ebuild
ebuild: if [ -f /var/spool/moab/.moab.key ]; then still need ${ROOT} there (In reply to comment #5) > If mschedctl fails, it doesn't return 1, and this is the preferred way to > shutdown moab. Should I add start-stop-daemon if the mschedctl command fails? How do you know if it fails if it always returns 0? :) Perhaps you could look at the mschedctl code. Maybe it's just a glorified script which runs kill (in which case it's easy to replace by s-s-d). Otherwise, perhaps you can patch it to return a meaningful exit code, and fall back on s-s-d if it fails. Or maybe you can just run both, but you'll have to test how s-s-d behaves if you ask it to stop a process that has already gone away. > Moab stores it's configuration files in /var/spool/moab rather than /etc. I > basically emulated the Torque ebuild, as Torque behaves the same way. Is this > unecessary? And you expect the user to modify these config files in some conditions? If so, the env.d file is fine.
(In reply to comment #7) > (In reply to comment #5) > > If mschedctl fails, it doesn't return 1, and this is the preferred way to > > shutdown moab. Should I add start-stop-daemon if the mschedctl command fails? > > How do you know if it fails if it always returns 0? :) > Perhaps you could look at the mschedctl code. Maybe it's just a glorified > script which runs kill (in which case it's easy to replace by s-s-d). That was a typo above, it does return 1 on failure, at least in the cases I tested. However, they are catching the TERM signal and shutting down in the same manner, so using start-stop-daemon will have the same effect. > > Moab stores it's configuration files in /var/spool/moab rather than /etc. I > > basically emulated the Torque ebuild, as Torque behaves the same way. > > And you expect the user to modify these config files in some conditions? If so, > the env.d file is fine. > In nearly all conditions I suspect the files will be modified. Otherwise one shouldn't be paying Cluster Resources for Moab's functionality!
Created attachment 123995 [details] moab-init.d Using start-stop-daemon, and added a pause when restarting (Moab takes a little while to shutdown).
Created attachment 123997 [details] moab-5.1.0_p5.ebuild Added some directories that weren't being created, $ROOT when checking for key file, and suid use flag (is this the preferred way?) to handle adding the setuid bit on /usr/bin/mauth, which allows regular users to read the .moab.key file in order to submit and query jobs.
IMO you might want to add a check_license and/or a warning about it being an evaluation unless they put the license file in the right place (if they have one). (In reply to comment #10) > Created an attachment (id=123997) [edit] > moab-5.1.0_p5.ebuild > > Added some directories that weren't being created, $ROOT when checking for key > file, and suid use flag (is this the preferred way?) to handle adding the > setuid bit on /usr/bin/mauth, which allows regular users to read the .moab.key > file in order to submit and query jobs. >
Created attachment 124076 [details, diff] moab-license.patch Alan was correct, we need a license check. I've added such, assuming that we can put moab into /usr/portage/licenses. It should be noted that to even get the package download, one has to agree to this already I believe (I know I did). I can upload the license too if necessary.
ebuild stylistic nitpick: for i in $homedirs; do ${homedirs} please Latest init.d version has some indentation oddities. Is the restart()/sleep hack really needed in all these init scripts? No need to repost any of the above. Looks good to me otherwise.
Well, I changed jobs and no longer have access to Moab. Closing, but feel free to reopen if you want to proxy maintain.
