Hi Jason,
Unless someone else is already doing it, I'm planning to contribute a Fedora/RHEL compatible RPM spec file for H2. I probably won't start working on it until you release an initial tarball, but I've looked through the code and have a few questions/comments:
- For the RPM I'll probably move the settings dir to /var/lib/hastymail2/user_settings which seems more FHS compliant.
- Will there also be an attachment dir like in H1? If so, I'd prefer that the RPM put it in /var/spool/hastymail2/attachments. To make it easier for packagers, please use separate config file entries for settings and attachments (unlike H1).
- Now that there are 2 config files, hastymail2.conf and hastymail2.rc, it might be better to put them both in a /etc/hastymail2/ directory.
- Ideally, future plugins would also be packaged as RPMs. It would be cleaner if a plugin RPM could be installed and activated without the RPM needing to modify the .conf file and build a new .rc file. Is it a requirement that an H2 admin be able to install a plugin but not activate it? If not, maybe you could just parse hastmail2/plugins for the list and leave them out of the conf files.
The above comments probably would also apply to debian packaging, but I don't know much about that...
Thanks,
Mark
Mark,
Nobody is currently doing this as far as I know, so your offer is greatly appreciated.
- I have no preference for the default settings directory so if /var/lib/hastymail2/ is the right place then that works for me.
- There will be an attachment dir (since there pretty much has to be), so I will create a separate config file entry unlike hm1. The lack of a separate setting for this was more due to laziness than prudence really.
- I have no objections to a hastymail directory in etc for both of these files.
- The point of having to activate a plugin via the config system is to limit overhead. I don't have a good solution for overcoming the limitations this places on having plugins as separate rpms, but surely we can find a solution that addresses both concerns.
Jason Munro
I've written the first rev of an RPM spec file. Apparently there's no
way to attach files here, so I'll send the actual spec file and an RPM
via email. I'd like to get your feedback on the following and do
another rev before you post it for testers. Otherwise, feel free to use
and publish it as you see fit. Note that this RPM includes a patch for the DateTimeZone issue I reported in another thread.
- I've moved the following 2 file locations:
/var/hastymail2/attachments/ -> /var/spool/hastymail2/attachments/
/var/hastymail2/user_settings/ -> /var/lib/hastymail2/user_settings/
IMO, these are more FHS compliant (at least the way RH/Fedora interprets
it). Let me know if you agree. If you do, it would be easier if you
change these in the source. (I'd also suggest using /etc/hastymail2/ instead of /etc/hastymail/ just for consistency.)
- What should the ownership and permissions of the .conf and .rc files be? What are the security implications (if any) if an unprivileged local user can read the site_key?
- I'm assuming that the name/version convention for the release will be
Hastymail2 2.0 (and not Hastymail 2.0 or Hastymail2 1.0 or...). Is that
right?
- Should the RPM add a tmpwatch cronjob to clean up the attachdir, or do you do something else to make sure files don't get orphaned there?
- What's the purpose of the empty .htaccess file in the root of the hastymail2 dir?
Also, the options page doesn't work. Is that a known issue? I don't think my RPM could be doing anything to break it...
I'm not a Fedora contributor and I don't plan to become one, but this
RPM attempts to follow their guidelines. If you or someone else wants
to contribute it to Fedora or EPEL, it should be able to be accepted
with minimal changes.
So far I've only tested on CentOS 5, but it should work on any recent
CentOS/RHEL/Fedora release. I'll test on other platforms before
release. Are you running one of these and can you build RPMs on it?
Regards,
Mark
One more thing in addition to the above questions:
The only other setting that the RPM modifies is that I make host_name an empty string. Should this become your default? AFAICT, the current default of localhost will only work if the only client connections all come from localhost.
Mark,
Thanks for all this work and feedback. I personally don't run any RPM based systems so I will defer to your expertise insofar as the specifics. I don't see any problem changing the default locations for the created directories. Btw the current SVN has an update for the DateTimeZone issue you mentioned.
The permissions of the conf and rc file should be as limited as possible but still readable by the web server software. The site_key is used to encrypt users account passwords while they are logged in (in the PHP session). I will probably add the "apache include" key ability like hastymail 1 at some point as well.
As for the naming and version numbering I have not really thought about it :)
There is definitely situations in which left over attachments should be cleaned up. There is more work to be done in Hastymail to keep them from being left on the server in those cases but there is no built in clean up routine.
The empty .htaccess file has no purpose, I just did not notice it was in there when I put together the release :)
The option page works fine here and on all my other test setups. What specifically are you having problems with?
Thanks again for the work, having packages that ease the installation process is always a great way to increase adoption.
Take care,
Jason
You are right, it makes more sense to leave it blank by default. I will change that in SVN
Thanks for the feedback,
Jason
Hi Jason,
I'll email you shortly an updated RPM and SPEC with the following changes:
- Temporary work around for DateTimeZone version issues
- Add daily cron job to clean up old (>10 days) attachments
- Change conf and rc files to 0400 apache:apache
- Remove unneeded .htaccess file
It's still based on beta1 rather than the new snapshot you just posted. I'll send you an update when you publish a beta2. I'd still request that you change the default locations for attachments, user_settings and /etc/hastymail2, but it's really no big deal to making the RPM if you choose not to.
Regarding the name and version, I'll go with what I assumed until I hear otherwise from you. The only possible issue is that if it changes, upgrades from beta to release may need to be forced manually - beta testers should expect these kind of quirks.
IMO, the RPM I'm about to send you is pretty solid and I'd like to see you distribute it for testing. Also, can you import the .spec file into SVN so that other eyes can comment and help improve it? I'll just send you diffs as it changes for bug fixes and new releases.
Regards,
Mark