| Summary: | sys-cluster/moab-5.1.0_p5 (New package) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Justin Bronder (RETIRED) <jsbronder> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | hp-cluster |
| Priority: | High | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
moab-5.1.0_p5.ebuild
moab-init.d 25moab (env.d) moab-5.1.0_p5.ebuild moab-init.d moab-5.1.0_p5.ebuild moab-license.patch |
||
|
Description
Justin Bronder (RETIRED)
2007-06-28 15:28:52 UTC
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. |