On 19/07/2024 09:24, Alessandro Baggi wrote:
Il 19/07/24 02:38, Willy Sudiarto Raharjo ha scritto:
if you notice on postgresql.SlackBuild, we have this commands:
mkdir -p $PKG/var/lib/pgsql/$PG_VERSION/data
chown -R postgres:postgres $PKG/var/lib/pgsql
without having postgres user and group, this would fail and the
files/directories will not have correct permission for the application
Hi Willy,
in this way, yes if user will not be created the chown command will
fail, but at this point why not put the chown,user/group creation
commands in doinst.sh and remove the statement that requires postgres
user/group?
I think it is more genuine. For example I build my packages inside a
VM, then I install on my workstation. Here, on my workstation (and on
other machines where I will install postgresql package) without the
user/group creation postgresql "cannot be used" as configured so I'm
forced to create them manually, plus configuring
rc.local/rc.local_shutdown, while this should be done during package
installation.
For example, I have an automated build script to compile all needed
slackbuilds. If I add a new package that requires a specific
user/group definition the automated script will be stopped by that
requirement but if provided inside doinst.sh the automation will work.
From my point of view if an operation needs to be done many times, the
right solution is automate it (this is one big advantages of IT).
Another thing that could be inserted in the doinst.sh (for services
that require to start on boot) is populating rc.local with the correct
statement (if ..... /etc/rc.d/rc.service start...fi) with the caution
to not rewrite the same "starts statements" if already defined (maybe
used in upgrading the package)
In the current state the package installation is not complete because
it misses some points:
1. User/group privileges configuration that are required by the
software to run (as shipped in the slackbuild)
2. Configuring and prepare the system to start/stop the service (if
enabled) during boot/reboot/shutdown process
3. A clean process during package uninstall that clean created
user/group, start/stop system configuration in rc.local/rc.local_shutdown
My 2 cents,
Alessandro.
Although I agree it would be more convenient if users/groups and
rc.local/rc.local_shutdown entries were done automatically (I have a
printer driver which would benefit), these extra actions can be
automated outside of the slackbuild script itself.
You mentioned you have a build script. You can add the user/group
creation in that.
for example, in one of my scripts I have
#lets create required avahi user and group if needed
if [ `cat /etc/group|grep avahi|wc -l`x = "0x" ]; then
groupadd -g 214 avahi
fi
if [ `cat /etc/passwd|grep avahi|wc -l`x = "0x" ]; then
useradd -u 214 -g 214 -c "Avahi User" -d /dev/null -s /bin/false avahi
fi
You would also need an install script to do the same. (and the
startup/shutdown stuff as well)
I use such a script for the avahi and epson-inkjet-printer-escpr2
packages. one needs user and group, and they both need
auto-startup/shutdown entries. denyhosts is another which should be
started from rc.inet2 so it is running before sshd starts, but after the
network is up.
As there are so many "special case" packages, it is usually left for the
admin to externally script their preferred handling, and keep the doinst
scripts as minimal as possible.
Unless there is consensus on a approach that is not invasive eg. is
optional; such as a env variable which could be set if this stuff was
wanted to be run on install,
eg:
SBOAUTOMATE=yes; export SBOAUTOMATE
then in the doinst.sh
if [ "x$SBOAUTOMATE" = "xyes" ]; then
#do extra setup tasks automatically
#....
fi
it's not likely to get much traction.
regards, Tim
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
_______________________________________________
SlackBuilds-users mailing list
[email protected]
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
