Hi David,
Through our discussion on IRC about the items 1-3 and which way to solve
them, we seem to have ended up at trying to solve items 4-8 now, so, as
nobody commented on those yet, I'm sending my comments below.
The long and the short of it is the following proposal.
> If you have any thoughts or suggestions could you please comment before we
> start implementing the changes.
>
> We believe items 1-3 NEED to happen, the remaining items SHOULD happen
> depending on your responses
>
> 1. Only ever run LedgerSMB using Starman (High-performance preforking
> PSGI/Plack web server)
> 2. Only ever bind Starman to localhost
> 3. Always reverse proxy Starman port with either NGINX (preferred) or
> Apache
>
> Generally, I'd say the default should depend on what's already available
on a system. If Apache is available and installed, we'd want to support
using that, while if Nginx is installed, we want to bind to that. If
*neither* is installed, then, yes, choose one.
>
>
>
> 1. At installation create a system user "*ledgersmb*"
>
> Ok. And the database user won't be named that anymore in the future, so
there's no confusion regarding the type of user which is being referred
to? It's the intent to run the starman process under this user, right? So,
it's a low-auth-level user, much like "nobody", but with a separate
"namespace"?
>
> 1. At installation create a system group "*ledgersmb-admin*"
>
> Ok. What's the purpose of this user? To be the group to run the starman
process under? If not, then what does the starman user get run as, and what
is the role of this group?
>
> 1. all LedgerSMB files should be installed in a single versioned
> directory (eg: /usr/share/ledgersmb-1.4.26 or /opt/ledgersmb-1.4.26)
>
> If this is to support multiple simultaneously installed versions, then it
works as long as these versions don't have different versions of the same
library as their dependencies. I think your *only* way to full independent
installations is to use Perl's mirror of Python's 'virtualenv': local::lib
-- which installs *all* dependencies in a separate directory with the
correct dependency version.
>
> 1. the install directory and contents should be owned by user
> *ledgersmb* and group *ledgersmb-admin*
>
> Ok. I'm not sure I understand why we need this: all Perl libraries get
installed as root:root rwxr-xr-x. It applies to all global libraries,
including all of LedgerSMB's many dependencies. I think root:root rwxr-xr-x
should work fine for us: it's not like we're trying to stop people from
looking into these files are we? And if we are? Doesn't that provide a
false sense of security? Anybody can just download these files from the web
and install them in their home directory and start their own instance...
Other than that, you describe a pretty complex system of permissions.
There's a major downside to the system you propose: it's highly complex,
yet the software we're writing we try to keep as simple as possible,
because of the fact that we are already experiencing that people (users)
find it too hard to install correctly. I think that adding a highly
non-standard permissions pattern to the mix is asking for trouble there.
>
> 1. the install directory and contents should have the following
> permissions
> For Executable files (s--r-xrw---- | 4560)
> - r - x for owner
> - r w - for group
> - - - - for other
>
> For Non Executable files (r--rw---- | 460)
> - r - - for owner
> - r w - for group
> - - - - for other
>
> For Directories (-s-r-xrw---- |2560)
> - r - x for owner
> - r w - for group
> - - - - for other
>
> My idea would be that the default starman process hosting ledgersmb, runs
as ledgersmb/ledgersmb-admin (perms dropped from 'root' at startup) and the
files in the install dirs are all simply root:root rwxr-xr-x. That way, the
starman process can read what it needs, yet it can't modify the code it's
running.
If individual users want to run their own starman instances, the same
applies to those instances, except that those can never run on a
priviledged port (as always).
>
> 1. The temp dir configured in ledgersmb.conf will need to be owned by
> user *ledgersmb* and group *ledgersmb-admin*
>
> I would argue to the contrary: we simply shouldn't be creating a temp dir
at all and for all our *temporary* files, simply use /tmp. That's what all
processes do. If however we want to generate *log* files, then we should
generate log files to a logging output directory with appropriate
permissions.
My personal opinion is that it's a huge mistake that we ever created a
/tmp/ledgersmb directory under the user that happens to run code which
includes LedgerSMB::Sysconfig.pm.
>
> 1. The temp dir would need these permissions (sstrwxrwx--- | 7777)
> - - - s for flags
> - r w x for owner
> - r w x for group
> - - - - for other
>
> Rather, I'd simply want to use /tmp. We're not special, if it works for
others, it should work for us. Don't try to reinvent the wheel, do the
tried-and-tested. That both reduces the burden on us as developers, because
we don't need to come up with new solutions, but it also greatly simplifies
using and maintaining an installed instance as it does what admins expect.
>
> 1.
> 2. Any system users that need to be able to modify files in the
> LedgerSMB dir's would need to have *ledgersmb-admin* added to their
> groups.
>
> Ok. But nothing should be changing the files in the LedgerSMB dirs: only
software installs should. That's why the templates moved to the database in
1.4. And that's why I think 'root:root' should be Just Fine(tm). Any
Starman (global/startup) configuration options can be stored in
/etc/ledgersmb/<version>/... or /etc/default/ledgersmb-<version>.
Running LedgerSMB using Starman and a reverse caching proxy like nginx has
> significant performance benefits due to both the way Starman preforks and
> handles Perl assets, and the static asset caching offered by the proxy.
>
Yup.
> There is an additional benefit to running via Starman, it is less likely
> that an error in a latex template (for example) will cause a hard failure.
> This has recently been shown to be an issue with the current debian
> package for 1.4.25 available from our repository http://apt.ledgersmb.org
>
Well... That discards the experience John had that for a long time he
*could* execute his business processes on CGI, but not on Starman. So, the
other way around is true as well. At this time, I personally develop using
Starman, so bugs are likely called out the earliest on the Starman install.
However, I think we probably want to create a Travis CI test setup which
specifically tests the CGI setup, if we want to support that as a secondary
option, still.
That way, errors get caught early enough not to affect releases.
> Running as a specific system user improves security, and assists with
> running multiple instances on the same system.
> The restricted permissions take this a step further to make it harder for
> things to be broken or attacked by other processes on the system.
>
True, but if 'root:root rwxr-xr-x' doesnt' do enough for Perl code?
> Keeping everything from the LedgerSMB tree in a single folder instead of
> splitting amoung multiple system dir locations is necessary for running
> multiple instances on a system, especially if there will be more than one
> version of the code.
>
Running multiple instances is probably beyond the immediate scope of trying
to be easy on our users -- although admittedly, it could help some of the
people that try to run the software in a hosting scenario. But can't we
create a flag or some option or environment variable which indicates to
Starman/LedgerSMB which config file it should read? That way, we can run as
many as we want, yet still use the usual Debian/RH/... structure for
spreading config files over the filesystem. ("When in Rome, do as the
Romans do..."?)
> I am certain there are ways to work around that, but simplicity is often
> the best solution.
>
Things like the docs dir can have a symlink /usr/share/doc/ledgersmb-1.4.25
> that point to the real dir
> The same goes for manpages if we want to.
> NOTE: for an official debian package (in the debian.org archives) we may
> have to split things up to comply with their policy,
>
You mention simplicity, but needing to split up packages in Debian doesn't
sound like we're "going simple". Why would we need to split up the package?
And if we do, is there anything we can do to make it so we don't (yet we do
comply)?
> but there is precedent not to.
> Also as debian doesn't allow version updates to packages for the life of a
> release Official Packages for LedgerSMB are of minimal benefit.
> We are better to point people at our own repository.
>
Ok. We've been over that on IRC: I personally think that there's no problem
to provide packages through the official repository. I've been using a 5
years old Subversion client just last week and it worked perfectly fine for
my uses. If I want something newer, I can install the version from
backports. I think we should agree to disagree, hoping that others chip in
on the subject.
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
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
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
