Hey everyone!
Firstly, I wanna say for the excellent work you guys have done for Smack and Jive! It’'s really a wonderful tool set.
But anyways, I wanted to know if there was some way I could get at the RPM SPEC file. I couldn’‘t find it in the source or in the SVN repository (but perhaps I didn’'t look hard enough).
Thanks!
Karl,
We actually use a tool called Install4J to generate the RPM so don’'t have the SPEC file in any raw form. The install4j script is in SVN so you could definitely check it out (Install4J has a 30 day free download I think).
Is there anything about the RPM that you would suggest be changed? We don’'t have direct control over the SPEC file but there are various toggles we can turn on and off.
Regards,
Matt
Actually, yes, there are a few things I would recommend for the RPM.
Firstly, RPM should never use /usr/local/*; that’'s for installing software you compile yourself. So, the /usr/local/bin/messenger script should be in /usr/bin instead.
And, honestly, I don’'t see the need for the ‘‘messenger’’ script because the init script handles all that. Which brings me to my next suggestion: install your init script into /etc/init.d so Jive Messenger can be started like all the other services on a Linux box. See the following page:
http://www.novell.com/coolsolutions/feature/11256.html
A more general suggestion is to make Jive more FHS-complaint:
put all lock files in /var/lock/…
put all log files in /var/log/…
This is because a lot of sysadmins will make /opt and /usr read-only.
Other than that, thanks for the excellent Jive server. =)
Firstly, RPM should never use /usr/local/*; that’'s
for installing software you compile yourself. So,
the /usr/local/bin/messenger script should be in
/usr/bin instead.
Weird. I was pretty sure that we always installed to /opt and not /usr/local. At least that’'s what it says in the installer tool. Are you seeing the RPM install to /usr/local on your box?
And, honestly, I don’'t see the need for the
‘‘messenger’’ script because the init script handles
all that. Which brings me to my next suggestion:
install your init script into /etc/init.d so Jive
Messenger can be started like all the other services
on a Linux box. See the following page:
Do you think it’‘s a “best practice” for an RPM to do the init.d changes? I’‘ve been told by others that most admins would rather create the init.d setup themselves, but I’'m open to all opinions.
A more general suggestion is to make Jive more
FHS-complaint:
- put all lock files in /var/lock/…
I’'m not aware of any lock files. Do we have some being created?
- put all log files in /var/log/…
I’'d like to avoid that. By having the logs always in a consistent place, that lets us do the log viewer in the admin console and document exactly where people look for logs in a cross-platform manner.
Regards,
Matt
Weird. I was pretty sure that we always installed to
/opt and not /usr/local. At least that’'s what it says
in the installer tool. Are you seeing the RPM install
to /usr/local on your box?
My apologies. I had /usr/local/bin/messenger because someone else had created it on my machine.
Do you think it’'s a “best practice” for an RPM to do
the init.d changes? I’'ve been told by others that
most admins would rather create the init.d setup
themselves, but I’'m open to all opinions.
Well, as a former RPM maintainer, that’'s what I did. And this is what it seems everyone is still doing.
FreshRPMs does it (http://freshrpms.net/). Example: http://stentz.freshrpms.net/rpm.html?id=299
Packman does it (http://packman.links2linux.org). Example: http://packman.links2linux.org/?action=615
And this is also what RPMs from the distribution maintainers do.
I’'m not aware of any lock files. Do we have some
being created?
Correct me if I’‘m wrong, but isn’'t embedded-db/messenger.lck a lock file?
- put all log files in /var/log/…
I’'d like to avoid that. By having the logs always in
a consistent place, that lets us do the log viewer in
the admin console and document exactly where people
look for logs in a cross-platform manner.
Yes, that’‘s the advantage, and I figured this is why you guys were putting everything under the Jive installation directory. It’‘s a choice between convenience and consistence, and standards-compliance and a shred of extra security, IMHO. Your choice allows Windows server admins to know exactly where the log file would be on a Linux installations of Jive, although a seasoned Linux sysadmin with no prior knowledge of Jive would wonder why he/she can’'t make /opt read-only, and gripe about its non-compliance to the FHS.
Thanks for the response, Matt, and keep up the great work!
noodlez84 makes some very good points. As someone else who has had to tinker with the release RPMs, I’‘m glad to see that there’‘s more interest in streamlining them. I agree with noodlez84 when it comes to the initscript part. With some cleaning/tweaking (and perhaps a more type-able name), I see no reason why the init setup shouldn’'t be built in to the RPM.