On 03/04/16 02:58, Erik Huelsmann wrote:
I'm not so sure about that, In my experience requiring (or recommending) the httpd virtual package results in getting apache installed by default.
I haven't investigated to see if this is a general limitation of the packaging systems or with the way the packages have been built, but I suspect the former.
The only real certain method I can think of is to leave the specific httpd packages we support as suggests, and in our package install scripts make sure one of them gets installed.
Yep, I'd prefer to use starman's ability to drop privileges as that allows the use of privileged and unprivileged ports, while using systemd to set the user to run as only allows unprivileged ports to be used.
Hmm, I'd say /usr/share/doc/ledgersmb/* would be an odd location to put these files, as a sysadmin I'd expect to find documentation there (or links to it) that is not essential to the uperation of the software, not content that is required for the software to function.
as for /usr/share/ledgersmb/* if that is the root of the install tree then yep, I'd agree it is a sensible location, but if it's not then we need a generic "make install" process that can by used by all platforms to "copy" our templates across. This really shouldn't be handled in different ways by different packages (treating a tarball or source install as package types)
As for the permissions, these files are directly web presented data, I'm surprised that root:root is what is used.
apache and other httpd's have traditionally (by default) required all served files are owned by the running user (www-data) and not editable by that user.
If we refer to this article on serverfault.com in-particular the section "You can have your cake and eat it too" (you will need to read the previous section as well) there is a nice explanation of why I'm proposing the permissions that I am. ie r-x rwx ---
Ok, so I can't actually think of a way to eliminate the need for a temp dir, some things simply need to be written to file for a while. (eg: tempfiles during a print process, or PDF creation)
As for tools like "create-company-database.pl" (which by the way doesn't exist) the proposed scheme would no more prevent it being run than having it owned by root.
The running user is still going to need to get elevated privileges somehow, our current "delete-company-database.sh" script uses "su" for this, which probably should be fixed to not internally get elevated permissions, but let the executing user do so as there are a variety of ways such as sudo, calife, userv to name a few of at least 10 open source options, and there are commercial options out there as well.
Basically yes, at times we will need privilege escalation, but that should not be done by us running as a normal user, instead the user should use system specific tools to gain elevated privileges to run the script.
If we port all of our scripts to perl instead of bash then we can be smart and drop privs for everything that doesn't require them in a system agnostic way.
Agreed for system updates (including ledgersmb updates) but things like translations and potentially plugins (when they are supported and written) are a common thing to do as a "software" admin user.
I'd think that there are issues with our code structure yes. but on the other hand I can't see a way around creating a temp dir.
Making it so that ALL programs / scripts that are in the LedgerSMB tree HAVE to be run as the Installed User solves the problem.
It becomes impossible for the temp dir to be owned by anyone else that way.
Temp Files used for printing probably come under that heading.
Ok, so we agree that we need a process specific user that owns our files in /tmp and that those files should generally be r-- --- ---
You're thinking a /tmp/ledgersmb dir makes things complicated as if there are multiple users wanting to put files in that dir we get permissions issues.
I would propose that we actually want to have our temp dir's named more like....
$user is the running user
$port is the starman port assigned to that instance
Which incidentally is the same naming scheme I'd suggest for ledgersmb.conf (ie: ledgersmb-$user-$port.conf) for multi instance systems
(keeping in mind that we will be able to pass a config file path/name to the process in an env var)
Yep, I'm happy with needing to allow template, and CSS to exist in another user specified dir, but only as a manual config change done by an admin, and really we shouldn't care or even specify where that will be.
Unless the config option is explicitly set in ledgersmb.conf we should use our built in files (which stay in tree)
So, the use of ledgersmb-admin would not normally be needed, except for system users that have a *specific* need such as local customizations etc
Using this group allows that to be done without requiring root access (which any other method would)
I don't know the answer to that, but I do know that the current method of installing perl modules nor available from the system repo (ie: using cpan) can easily go wrong, if the user chooses the wrong cpan config option they can be installed in system perl dir's instead of local dirs. this is a know cause of system wide perl issues if the version of a module being installed clashes with other uses on the system.
I'm not certain that all packaging systems correctly remove old files without a full uninstall, possibly even a purge.
In our existing debian packages a remove only handles running "apache2_invoke disconf ledgersmb.conf"
Which may leave traces of an old system behind.
Also our existing .deb packages do not handle templates and CSS in the manner you describe.
Instead of testing for changes and automatically replacing teh files if there is no change, or prompting the user to make a decision if there are changes,
the current packages keep the old versions of the entire templates, and CSS directories without exception.
I will guarantee that there are existing systems out there that have been installed and updated via our .deb's that are using CSS and templates that do not match with the appropriate source files.
We at least need to handle this as part of the package install by setting all of these files as config files so the deb packaging tools deal with it for us (which only works if we keep the files in tree I believe) or probably better handle it by commenting out any custom locations for these files (defaulting to the in tree shipped version) but provide a warning in both setup.pl and above the Main Menu saying that local customizations are not being used
I'm not so sure about sticking with packaging systems preventing this.
If our search path for a .pm during execution is /usr/share/local/ledgersmb:/user/share/ledgersmb and any old package installed files in /usr/share/local/ledgersmb but the current package installs in /usr/share/ledgersmb we have a problem.
If the original package is properly removed before the new package is installed then it's only a problem if local customizations have been made.
But, if multiple instances have been setup (eg: 1.4.25 and 1.4.26) that have a similar change made we, once again run into this issue.
I agree, but, my suggested fix is to use symlinks to expose things in locations that a user/admin may expect to find them instead of actually moving our files.
This is a method that has been used by other packages.
The exception to this would be templates and CSS which I still think should stay in tree but via the config options a local copy could be provided out of tree if customizations are to be done locally.
To use backports isn't quite that seemless, looking at
You need to add the sources entry for $release-backports, and possibly even $release-backports-sloppy as well
Doing a dist-upgrade will require manual fixes to those entries also (from memory backports just get commented out on dist-upgrade)
It's unclear exactly what happens when a new package version is added to backports, It used to be that you had to manually install the upgrade by running apt -t... again, although that may have been resolved in wheezy and later
------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel