Am 26.01.2017 um 19:31 schrieb Dennis Clarke:
1) OpenSSL dependency dance
I removed OpenSSL 1.1 and compiled OpenSSL 1.0.2e from source
You'll probably have better luck installing Debian's libssl1.0-dev and
related packages, rather than installing it yourself. Plain libssl-dev in
Stretch is OpenSSL 1.1.
If you install stuff yourself from source then it is particularly unwise
to put it in /usr where it'll collide with files managed by dpkg - put it
in /usr/local or /opt.
I have always been amused by the defacto approach of Linux people
who compile software and install it into /usr/local as a way to keep
non-vendor software outside of /usr. Given that /usr/local is *inside*
the /usr tree of course
but it don't collide with the package manager which is the whole point
and so dunno what you find amusing at all
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
/usr/local
The original idea behind '/usr/local' was to have a separate ('local')
'/usr' directory on every machine besides '/usr', which might be just
mounted read-only from somewhere else. It copies the structure of
'/usr'. These days, '/usr/local' is widely regarded as a good place in
which to keep self-compiled or third-party programs. The /usr/local
hierarchy is for use by the system administrator when installing
software locally. It needs to be safe from being overwritten when the
system software is updated. It may be used for programs and data that
are shareable amongst a group of hosts, but not found in /usr. Locally
installed software must be placed within /usr/local rather than /usr
unless it is being installed to replace or upgrade software in /usr.
The POSIX and XPG4 approach has always been to provide some real
separation and install software in /opt/{vendor_name} with the config
files place under the /etc tree at /etc/opt/{vendor_name}
nothing different with /usr/local (it has the same hierarchy with bin,
sbin, etc) and there are additional good reasons to use it because it
has the same protections with ProtectSystem=true from get compromised
(on modern systems /sbin and /bin are just symlinks to /usr/sbin and
/usr/bin)
https://www.freedesktop.org/software/systemd/man/systemd.exec.html
ProtectSystem=
Takes a boolean argument or the special values "full" or "strict". If
true, mounts the /usr and /boot directories read-only for processes
invoked by this unit. If set to "full", the /etc directory is mounted
read-only, too. If set to "strict" the entire file system hierarchy is
mounted read-only, except for the API file system subtrees /dev, /proc
and /sys
created ELF file binaries. However the folks in the Debian project and
many other Linux distro projects often release software to the world
wherein there is no RPATH or RUNPATH data in the ELF dynamic section
and thus the libs needed are left to the runtime linker to sort out. In
this case they could be from where ever the user decides and if they
very dangerously use LD_LIBRARY_PATH then an over ride may be enforced
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
but that's completly offtopic, the whole reason why you never use /usr
as prefix for your own builds is that at any time in the future
something may introduce a new dependency and with random updates your
self built stuff get overwritten and in case something just pulls
libraries it will get *destroyed* because your unmanaged executable
stuff is still present in the version you did "make install" but it's
librarie sgot overwritten by the package manager which has no clue and
needs not have a clue that somebody did overwrite randomly stuff where
he ha no business to do so
The point of ALL of the above is that users of open software should
always have the freedom to build software on their own computers from
sources as they please and to install the results of their work as they
please. However a bit of caution should be used in the placement of
the resultant executables and the libraries such that they do not
affect the runtime characteristics of their distro. However the freedom
is there and the sources exist for very good reasons and if a user makes
the choice to dance in a minefield then by all means let them. However a
caution sign should be posted on the outer edge with some fine print
which says "you have the freedom to do so but here are some guidelines."
yes, you have the freedom to intall whatever you want where you want,
but the problem
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
