stop overwriting .service file on updates

[trex2000]

Hello, I am using a native install on an ubuntu server. After each update, the .service file is updated with a default one. This is bad, as I've done some modifications in the service file by adding startup parameters, and these get reverted on update.

[fuji246]

sorry about that, instead of changing the service file, we've changed to use env variable, see https://docs.lomorage.com/docs/Installation/lomorage-service/installation-ubuntu/#3-configuration-parameter-customization-1.

[trex2000]

That is not a nive solution in a productive environment. Please keep the command line parameters and stop overwriting the service files. There are several practices that server admins hate, ans this is one of them. It's unprofessional and prone to errors. So just don't. On 26 Nov 2021, 20:59 +0200, Jiantao Fu @.***>, wrote:

sorry about that, instead of changing the service file, we've changed to use env variable, see https://docs.lomorage.com/docs/Installation/lomorage-service/installation-ubuntu/#3-configuration-parameter-customization-1. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[fuji246]

@trex2000 , check the solution at https://askubuntu.com/questions/1348116/does-dist-upgrade-replace-service-files. The best practice is cp /lib/systemd/system/lomod.service /etc/systemd/system/lomod.service and then edit "/etc/systemd/system/lomod.service", and then sudo systemctl daemon-reload will use "/etc/systemd/system/lomod.service" instead. "/lib/systemd/system/lomod.service" is expected to be overwritten when upgrade. Using env variable is another option.

[trex2000]

I know how to update service files. The problem is that you are doing it wrong in the linux world :) You never update a service file if it was user-modified. All distro packages do release updates to service files from time to time, but in this case, the script copies it under the name lomod.service.dist-upgrade file, unless you answer with yes in the prompt before : Configuration file `/etc/mysql/my.cnf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version.*** my.cnf (Y/I/N/O/D/Z) [default=N] ?

This is how it's done properly.

The export of env variables is a dirty way and was ( unfortunately) introduced in the raspberry world as a normal habit by devs who didn't understand the way linux is supposed to work.

BtW: Another popular sw that messes up everything is python's package management :) There are hundreds of polls regarding this.

On 26 Nov 2021, 23:04 +0200, Jiantao Fu @.***>, wrote:

@trex2000 , check the solution at https://askubuntu.com/questions/1348116/does-dist-upgrade-replace-service-files. The best practice is cp /lib/systemd/system/lomod.service /etc/systemd/system/lomod.service and then edit "/etc/systemd/system/lomod.service", and then sudo systemctl daemon-reload will use "/etc/systemd/system/lomod.service" instead. "/lib/systemd/system/lomod.service" is expected to be overwritten when upgrade. Using env variable is another option. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[fuji246]

Thanks for giving the example, looks like adding conffiles file with "/lib/systemd/system/lomod.service" in it could give what you expected, however, after reading https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles, it mentioned that those in "/etc" is expected to be the place for user configuration. And as mentioned in https://askubuntu.com/questions/1348116/does-dist-upgrade-replace-service-files, "/lib/systemd/system/lomod.service" is expected to be overwrite, while "/etc/systemd/system/lomod.service" is not.

[trex2000]

Yes, normally you store the binaries in /usr/bin or /usr/local/bin ( if package is manuakky built or not installed via apt) , configuration always goes into /etc, and various libraries go into /usr/share, documentation into /man/doc, and logs into /var/log

When Unix systems were invented, there was a very good reason why this was done like this and ia way superior also now than the messy windows environment.

For example a sys admin can deploy various scripts to automate backups and cleanups.

For example, logrotate takes care of the rotation of the log files, so that they don't fill up the drive.Backup scripts can automatically backup configuration files that are expected to be placed inside /etc folder. Also, some people use regular HDDs mounted for /var/log location to avoid wearing the ssd while keeping system files that rarely change on a fast ssd.

Failing to keep this structure will render all these practices unusable, and gives terrible headaches to sysadmins.

Also placing binaries and everything else into /opt is not a good idea either, see the reasons above. /opt or optware is usually used in embedded systems like a router, for example, where you have  read only filesystem and if you wish to place additional binaries into a jffs flash or external drive, you do it by placing everything there, as the rest of the system is read-only.

But in a full debian System, as is the raspberry pi image itself, as well, everything should keep the linux directory structure, as above.

I don't want to be unfaithful, as you are doing great work with lomorage, and I really love it, but these small things will really annoy lots of sysadmins who want to deploy the product on servers.

On 27 Nov 2021, 09:57 +0200, Jiantao Fu @.***>, wrote:

Thanks for giving the example, looks like adding conffiles file with "/lib/systemd/system/lomod.service" in it could give what you expected, however, after reading https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles, it mentioned that those in "/etc" is expected to be the place for user configuration. And as mentioned in https://askubuntu.com/questions/1348116/does-dist-upgrade-replace-service-files, "/lib/systemd/system/lomod.service" is expected to be overwrite, while "/etc/systemd/system/lomod.service" is not. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[dwebfan]

@trex2000 thanks for using lomorage and loving it, please see inline.

Yes, normally you store the binaries in /usr/bin or /usr/local/bin ( if package is manuakky built or not installed via apt) , configuration always goes into /etc, and various libraries go into /usr/share, documentation into /man/doc, and logs into /var/log

Agree that most applications are installed under /usr/bin, or /usr/local/bin, on the other side, based on Filesystem Hierarchy Standard, or Linux Filesystem Hierarchy, /opt is also one directory to install add-on software package. And we are trying to make lomorage as add-on software and self-contained as normal MAC application. If people don't like it, they just need remove /opt/lomorage.

Also upgrade procedure is unmanaged and non-user invention because we want to make sure users can get all features automatically at the background. This is why it overwrites .service file on update currently. Environment variable approach is the one compromise solution having the flexibility to customized the running parameters. If you have other good suggestion, please let us know as well.

[trex2000]

Ok, I am afraid you really don't understand the mechanism of linux update procedure and did not work as sysadmin in a corporate environment.

I will write a script that fixes all this.

On 28 Nov 2021, 08:02 +0200, dwebfan @.***>, wrote:

@trex2000 thanks for using lomorage and loving it, please see inline.

Yes, normally you store the binaries in /usr/bin or /usr/local/bin ( if package is manuakky built or not installed via apt) , configuration always goes into /etc, and various libraries go into /usr/share, documentation into /man/doc, and logs into /var/log Agree that most applications are installed under /usr/bin, or /usr/local/bin, on the other side, based on Filesystem Hierarchy Standard, or Linux Filesystem Hierarchy, /opt is also one directory to install add-on software package. And we are trying to make lomorage as add-on software and self-contained as normal MAC application. If people don't like it, they just need remove /opt/lomorage. Also upgrade procedure is unmanaged and non-user invention because we want to make sure users can get all features automatically at the background. This is why it overwrites .service file on update currently. Environment variable approach is the one compromise solution having the flexibility to customized the running parameters. If you have other good suggestion, please let us know as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[dwebfan]

@trex2000 thanks a lot! If you like, would you please submit one PR at this repo? This is where our debian package is made. https://github.com/lomorage/lomod/tree/master/rpms-build/release/DEBIAN

[fuji246]

The best practice is cp /lib/systemd/system/lomod.service /etc/systemd/system/lomod.service and then edit "/etc/systemd/system/lomod.service", and then sudo systemctl daemon-reload will use "/etc/systemd/system/lomod.service" instead. "/lib/systemd/system/lomod.service" is expected to be overwritten when upgrade.