Date: Sun, 05 Aug 2018 22:11:34 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 230397] Ports system should not update configuration files without asking Message-ID: <bug-230397-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230397 Bug ID: 230397 Summary: Ports system should not update configuration files without asking Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: Individual Port(s) Assignee: ports-bugs@FreeBSD.org Reporter: ralph.sch@gmx.net Some time ago, the FreeBSD ports system has begun to automagically update configuration files for at least apache24 modules and php extensions (from = here on out: "Extensions") so that, when any mod_* or php*-* Port gets installed= (or uninstalled), existing configuration information is transparently updated to add (or remove) the associated Extension from the system. This is done without asking and it is also done without at the same time providing users with a way to opt out of that convenience. As a result, custom setups break every time=20 (A) An Extension is added or removed from the system;=20 (B) An Extension is updated due to there being revision, update, or other modification of the affected port(s) that cause it to be reinstalled. At the same time, whenever a Port is installed or removed from the system, startup information is left alone. So is, for the most part, their configuration information in $sysconfdir. Newly installed services, where applicable, do not get started automatically. This is expected behavior. Not so for installation, update or even removal of Extensions (ie. associat= ed Ports): if an administrator set up vhost-specific configurations for apache, php, or both, then on the next update run, there is a very real risk the sy= stem will stop working until someone restores the auto-updated configuration bac= k to what it was BEFORE the ports system decided to modify it. Best case, that a= dmin would set up configuration environments for both PHP and apache independent= of the system configuration... of course, in that case, auto-updating said sys= tem configuration would end up being no-op for all intents and purposes. Even if an admin chose a more standard approach - in this case, a single Ap= ache site with only a single PHP instance to back it -- there is still an issue = of auto-enabling newly installed ports. If such an admin chose to update their site configuration, in particular: one requiring a new Extension to run, th= en if that Extension conflicts with another Extension in whatever way, or if t= hat Extension segfaults for some reason, or in any other way does not work as intended, then through the simple act of installing the associated Port (for the purpose of testing it), that Extension gets Enabled without asking, potentially breaking the setup and the idea of "testing" becomes moot. This is, of course, not an acceptable situation, certainly not on productive systems, but not on any other system either. Strictly speaking, the only re= ason one might even consider wanting something like that would be along the line= s of XAMPP.... something that (I hope) FreeBSD *does not* want to emulate. I realize the feature "auto-updating configuration on port installation/removal" has been done for the sake of convenience, so that ne= wly installed software does not have to be enabled (or disabled) by hand. But there still has to be SOME way to opt out of this. Administrators must = be able to have final say when it comes to their setups. In some environments = one might even call FreeBSD compromised because of this: Modifications were done that nobody authorized, ergo the system state is no longer known and depend= ing on the situation the whole machine might have to get the sack. Therefore, I ask that the FreeBSD Ports system AT A MINIMUM implement an opt-out mechanism so that users can, without having to edit the Ports system itself, decide to NOT have their configuration data messed with. Ideally, of course, users would have to OPT IN to such a system instead, so that configuration data does not get updated unless users explicitly ask for that to happen. This on the assumption that such a feature is, indeed, desirable. =3D=3D=3D=3D This problem is, of course, NOT restricted to any given Port: php and apache are mentioned by name only because those, in my environment, are notable troublemakers in this regard.=20 Also, regardless what the current situation may be, no single Port in the FreeBSD Ports Collection should be permitted to make unauthorized changes to the system. It shouldn't be that hard to include appropriate flags in the OPTIONS framework (for example) where users can agree, or disagree, to have Port installations affect their system state(s). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230397-7788>