notqmail
notqmail copied to clipboard
notqmail
binary builds on openSUSE build service and locally
These files have been added for openSUSE build service on https://build.opensuse.org/project/show/home:notqmail
Description of the important files notqmail.spec - The RPM spec file notqmail-rpmlintrc - Containing rules to ignore few non-compliance errors (mostly FHS) on obs. notqmail-permission.* - These files are needed for SUSE Enterprise Linux (AFAIK) qmail-send.service - systemd unit file to start qmail-send notqmail.dsc - packages that opensuse build service should pull before doing a notqmail build debian/rules - The debian rules file deban/control - debian packaging control file debian/preinst,postinst, prerm, postrm - debian pre/post installation and deinstallation scripts
It's certainly fine to use the same PR, but will you separate the debian and redhat packaging in to separate commits?
The debian/ directory belongs in the root of notqmail.git, not inside the open the opensuse_buildservice directory. That is the location it is expected when you run dpkg-buildpackage and friends locally.
The debian/ directory belongs in the root of notqmail.git, not inside the open the opensuse_buildservice directory. That is the location it is expected when you run dpkg-buildpackage and friends locally.
OK. I will move the the spec file and the debian subdirectory to the root.
There are two ways of doing it. One is having debian subdirectory in the netqmail source tar ball and the other is by having a single tar file named debian.tar.gz. If I have the debian directory in the root, one cannot have debian.tar.gz. My plan is to do the following
- Modify Makefile to create debian.tar.gz in the opensuse_buildservice directory
- Have a _service file on opensuse build service notqmail directory which will pull notqmail.spec, notqmail.dsc, notqmail-rpmlintr, notqmail-permssion.* files, debian.dsc and debian.tar.gz. obs will then automatically pull all these files when triggerred using the web ui or using the osc command.
- A way to automatically trigger the build when anything is updated (just like travis). I am yet to figure this out.
- A script to automatically create the changelog from the CHANGES file.
Let me think of a way where both can be achieved and I will reorganize the files accordingly
- Building the RPM or debian locally so that any user can build the packages locally by just executing the commands rpmbuild or dpkg-buildpackage and
- Building the RPM and debian packages on the obs
Bump, @mbhangui and others. How can we help get this done and merged for 1.08?
Bump, @mbhangui and others. How can we help get this done and merged for 1.08? I just need to upload the latest tar.gz and do the build. I will do this tomorrow
Maybe just wait until 1.08 is out, the build is done and we are satisfied with it, and then merge it. I would like to avoid that we have a bunch of 1.07.9999 build with patches or weird tarballs and all that. YMMV.
I took the opportunity to rebase this on current master, adapt to some 1.08 changes, and add a second optional commit that drops some things that we want to remove in 1.09 even from the 1.08 packages.
I upgraded one of my servers using this RPM this morning and everything went fine. Some thoughts:
-is it the default to enable a newly installed service? -what happens if a user like me overrides the service by placing a modified copy in /etc/systemd, should we disable this on package removal? -/var/qmail/queue/lock/tcpto will show as modified when using "rpm --verify notqmail" because it is modified by the running services. Is there a way that we can mark it as "this file will be modified"? Mark as configuration file?
-is it the default to enable a newly installed service? Yes it is the default with almost all standard daemons (atleast on Fedora & CentOS). I have once in a while tried out Ubuntu and Debian. There too, these services get installed for startup by default. A good example is MySQL.
-what happens if a user like me overrides the service by placing a modified copy in /etc/systemd, should we disable this on package removal?
I don't have a definite answer to this. But in postinst, most packages do
systemctl disable servicename
-/var/qmail/queue/lock/tcpto will show as modified when using "rpm --verify notqmail" because it is modified by the running services. Is there a way that we can mark it as "this file will be modified"? Mark as configuration file?
I had this issue in indimail-mta. So what I did was
- have /var/indimail/queue in the spec file
- create the queue during postinstall of the package
- Files which can be created later but actuall belong to the package can be marked as ghost. e.g.
%ghost %config(noreplace,missingok) %{qsysconfdir}/tcp/tcp.smtp
Today I have built successfully binary builds for all the distros configured in OBS. Added Ubuntu 20.04 and openSUSE leap 15.2. I have done some modifications to the spec file and tested the installation on ubuntu 20.04 and CentOS7. I also tested the delivery. I had to make changes to fix few errors. The errors were all related to installing the systemd unit file.
Meanwhile I have also created docker & podman container images for notqmail. I will create a pull request for the same. The podman/docker images will use the opensuse build service to build the container.
Oh I forgot to mention. I have created a _service file for obs. Having such a file enables obs to pull the source archive directly from github
<services>
<service name="download_url">
<param
name="host">github.com</param>
<param name="protocol">https</param>
<param name="path">/notqmail/notqmail/releases/download/notqmail-1.08/notqmail-1.08.tar.xz</param>
</service>
</services>
I did some screw up. I pushed one commit which was supposed to be committed in the opensuse_buildservice branch to the docker branch. I don't know how to fix it
You can do something like "git checkout docker; git reset --hard HEAD^; git push --force" which would wipe the last commit from that given branch.
@DerDakon can you check the docker pull request. I see older commits that were related to opensuse_buildservice there. I don't understand how those have gone there because the docker pull request is something I just created few minutes back.
I have created the dockerfiles created for ubuntu and centos but don't want to push it till this is cleaned up.
The following changes have been made
- package the systemd unit file notqmail.service in debian builds exactly like the rpm builds
- run alternatives or update-alternatives command to have notqmail as an alternative mta. This will create link to /var/qmail/bin/sendmail in /usr/lib and /usr/sbin
- Create /var/qmail/control/me if not present. This allows you to start sending mail righ away after installing notqmail
- Create alias for root, mailer-daemon and postmaster. This allows you to send mails to root right away after installing notqmail. mails from cron, etc work after this change.
- On the opensuse build service, debian 7 has been removed
@schmonz There should be a proper email address ([email protected]) in notqmail.dsc, notqmail.spec changelog and debian/changelog. What would be a good address that someone can email in case of issue?
What would be a good address that someone can email in case of issue?
I've just added a packages@ alias, forwarding to dev@.
We can eliminate instchown in the debian builds if we write a small shim to create the queue. Something like this to create/fix the queue permissions. Here SPLIT and QMAIL comes from conf-split and conf-qmail
#!/bin/sh
set -e
create_subdirs()
{
cd $1
count=0
while true
do
mkdir -p $count
chmod 700 $count
count=`expr $count + 1`
if [ $count -eq SPLIT ] ; then
break
fi
done
cd ..
}
create_lockdir()
{
cd lock
if [ ! -p tigger ] ; then
mkfifo trigger
fi
chmod 622 trigger
chown qmails:qmail trigger
>sendmutex
chmod 600 sendmutex
chown qmails:qmail sendmutex
if [ ! -f tcpto ] ; then
head -c 1024 /dev/zero > tcpto
fi
chmod 644 tcpto
chown qmailr:qmail tcpto
cd ..
}
mkdir -p QMAIL/queue
chmod 750 QMAIL/queue
chown qmailq:qmail QMAIL/queue
cd QMAIL/queue
mkdir -p bounce
mkdir -p info
mkdir -p intd
mkdir -p local
mkdir -p lock
mkdir -p mess
mkdir -p pid
mkdir -p remote
mkdir -p todo
chmod 700 bounce
chmod 700 info
chmod 700 intd
chmod 700 local
chmod 750 lock
chmod 750 mess
chmod 700 pid
chmod 700 remote
chmod 750 todo
create_subdirs info
create_subdirs local
create_lockdir
create_subdirs mess
create_subdirs remote
chown -R qmails:qmail bounce
chown -R qmails:qmail info
chown qmailq:qmail intd
chown -R qmails:qmail local
chown qmailq:qmail lock
chown -R qmailq:qmail mess
chown qmailq:qmail pid
chown -R qmails:qmail remote
chown -R qmailq:qmail todo
We have most of the things we need in hier.c and instpackage.c already, but that one is not installed on the target system. I would still leave all the creation to deb and reduce the postinst script to only chown and chmod, which would give us at least correct package ownership tracking, as well as less things to care about in the script. Which means it's just instchown that we care about…
I wonder if we just go and write an "instscript.c" that does basically the same as instchown.c, but instead of executing syscalls outputs the shell commands, and then pipe that into something to be included in the postinst. This way the stuff doesn't clutter the filesystem.
Opinions?
When it comes to permissions, one needs to have proper permissions for the queue directories and the setuid bit on qmail-queue. debian installs everythhing as root. qmail-queue is easy. Just one chown, chmod and it can be set right. But the queue is a different story. Even for systems other than debian, there is nothing to fix the permissions of the queue unless you have the notqmail source downloaded somewhere. People do screw up things sometimes. Sometime it can be the admin who restores /var/qmail from a backup and finds notqmail not working.
So there is a need to have something to fix permission problem in rare cases, once in a while to repair the queue or recreate the queue. As we progress with more features tomorrow, there could be a need for a script to do more such things. I have seen one example - qmailctl which does few things
- stop start qmail
- build the cdb files for tcpserver
- queue status and more
We could decide on one such script/program and have a modular design for it. So that adding functionality should be that we add a plugin, the menu item, options and the actual functionality gets added without hving to modify the base code.
The below is just an example of the qmailctl script
Usage: qmailctl {start|stop|condrestart|restart|shut|kill|flush|rotate|reload|stat|queue|pause|cont|cdb|help}
start -- starts mail service (smtp connection accepted, mail can go out)
stop -- stops mail service (smtp connections refused, nothing goes out)
restart -- stops and restarts smtp, sends qmail-send a TERM & restarts it
kill -- Send kill signal to tcpserver, supvervise, qmail-send processes.
shut -- Shutdown entire svscan service.
flush -- Schedules queued messages for immediate delivery
reload -- sends qmail-send HUP, rereading locals and virtualdomains
status -- status of svscan process & qmail services
rotate -- rotate all logfiles (sending ALRM to multilog)
queue -- shows status of queue
pause -- temporarily stops mail service (connections accepted, nothing goes out)
cont -- continues paused mail service
cdb -- rebuild the tcpserver cdb file for smtp, qmtp, qmqp, imap, pop3 and poppass
Just tried the queue repair. It gives syntax error. if I fix that, it gives syntax error in some other part of script. Maybe it needs to be updated for the latest versions of python
./queue_repair.py
File "/home/mbhangui/Downloads/queue-repair-0.9.0/./queue_repair.py", line 69
'queue' : ('qmailq', 'qmail', 0750, 0),
^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
In pkgsrc, for similar reasons, I had the qmail package depending on http://www.netmeridian.com/e-huss/queue-fix.tar.gz and running it at post-install time. Maybe that is more suitable here?
In pkgsrc, for similar reasons, I had the qmail package depending on http://www.netmeridian.com/e-huss/queue-fix.tar.gz and running it at post-install time. Maybe that is more suitable here?
Yes. I use the same. It is written in C. It has saved me many times. The only thing is tht it uses stdio and the coding style will be so different than rest of the code base.
Well, maybe it’s not needed. The dependency is long gone from pkgsrc qmail. Sorry I’ve missed this, but what’s the reason it doesn’t work to have the package call ./instchown at post-install? pkgsrc does it like so: https://github.com/schmonz/pkgsrc-qmail/blob/master/INSTALL
Well, maybe it’s not needed. The dependency is long gone from pkgsrc qmail. Sorry I’ve missed this, but what’s the reason it doesn’t work to have the package call
./instchownat post-install? pkgsrc does it like so: https://github.com/schmonz/pkgsrc-qmail/blob/master/INSTALL
Copying instchown has a problem. It bails out if any of the doc or man pages are missing. When we package the man pages, we usually gzip it. Also the docs are moved to a standard directory /usr/share/doc/notqmail instead of /var/qmail/doc. So on debian, I'm linking /var/qmail/doc to /usr/share/doc/notqmail and /var/qmail/man to /usr/share/man. It stills bails out because the man pages are gzipped. But luckily the code sets the queue permissions before it tries the man pages. So at the moment I just ignore the error by doing instchown || true
Improving the tooling of qmail by importing what everybody wanted onto notqmail source... I feel it fits this goal from the wiki:
Following consensus, merging the best aspects into one implementation
https://github.com/notqmail/notqmail/wiki#what-are-the-projects-goals
When we have the spec files ready, we should add automatic packaging from OBS: https://openbuildservice.org/2021/05/31/scm-integration/