| |||||||||||||
GNU Guix launchesGNU Guix launchesPosted Nov 26, 2012 13:03 UTC (Mon) by pboddie (subscriber, #50784)In reply to: GNU Guix launches by davidescott Parent article: GNU Guix launches
When I put myself in their shoes and think about it I'm not sure that if I would choose to use a distro that made it easy for users to install packages without root or some administrative proxy permission. Unless you take away the compilers and, given the availability of binary installers for certain applications, unless you take away the right to download and run software - you can get pretty far by playing with the mount options, at least for the latter - then you have to accept that people will be able to run non-system software. For some kinds of users, imposing such restrictions is probably feasible and acceptable for all the usual reasons and according to the rules of the workplace, but when you have people who develop software unable to conveniently acquire and run software - setting noexec on the partition where they build their software isn't going to be very productive - then everybody has to ask themselves how much time is being wasted because of "policy". The perverse outcome of the conflict between policy and productivity is the proliferation of the technological sledgehammer that is the virtual machine, resulting in even more environments that need to be configured and managed properly, when the technological nut was just the installation of a handful of packages, potentially under a non-root user's privileges, that could have been done in a few seconds had the package manager permitted such a thing. I agree with you about not letting people install anything and everything - I worked in an environment once where people thought it was fun to click through on the "funny game/video/picture" attachment in Microsoft Outlook, and it was obvious that such activities weren't exactly going to end well - and I also agree that where an employer doesn't trust its employees sufficiently, that employer shouldn't expect things to get done in a timely or effective manner, but I also think that distributions should entertain the use-case of non-root package management for places with more enlightened administration policies where such features, if enabled, would be a clearly superior alternative to handing out administrative privileges.
(Log in to post comments)
GNU Guix launches Posted Nov 26, 2012 14:11 UTC (Mon) by davidescott (guest, #58580) [Link]
Two comments.
I'm not saying that policy is always sensible, rather that policymakers have the right to make it what they want. If the policy is swiss cheese to anyone who knows what a compiler is that nonetheless might meet the policymakers goals.
I disagree with your description of the Virtual Machine as a technological sledgehammer. VMs make it trivial for "Systems" to hand out sand-boxed units of server space, without requiring any domain specific knowledge about how exactly those servers are going to be used.
I just don't see who really wants "unprivileged package management." In an ideal world where packages never conflict and there are no bugs it sounds great, but when security/functional upgrade X breaks Alice's programs, but is required for the well functioning of Bob's, then the admin has to step in and fix the conflict. If I'm that admin, I'm just going to hand out VMs to everyone who needs one and reduce a space of 2^N potentially conflicting configurations to N independent systems. If the package manager is capable of allowing multiple version installations for every user then it is just implementing containers (AKA VM-lite) and we are talking about the same thing.
GNU Guix launches Posted Nov 26, 2012 15:05 UTC (Mon) by pboddie (subscriber, #50784) [Link]
Well, I was just saying that it's frustrating when people are in a situation where they could install an application in a few moments if they were only allowed to, but instead are obliged to retrieve and compile the dependencies as well as the application itself from source, replicating the work already done by the packagers, with the only difference in the outcomes of these two activities currently being that the former will put files in special places whereas the latter will put them in user-writeable places, and with no difference in the outcomes if the package manager could just install stuff in a user-nominated place anyway. (I'm not advocating that users would get to install their own stuff centrally.)
In other words, when the choice between wasting a few minutes of "admin time" and a few hours or days of "user time" once again goes against the user, this usually plays out fairly badly after a while because people tend to find their own ways of working around constraints that they don't regard as acceptable: that's just the way people deal with social or institutional restrictions. So when some project group suddenly has their own server running their own choice of software, and where their manager is more or less able to shout down various people in the hierarchy about needing to get the job done, and where some administrator has to go and negotiate a compromise, no-one should really be particularly surprised that it reached that stage.
That said, I very much have the impression that people are continually surprised at such events because they either fail to anticipate predictable human behaviour or because they believe that the policies that deter such behaviour will act as a sufficient deterrent. Consequently, from such a static viewpoint and contradicting common experience, any need for more flexibility surely cannot exist for those people. (They presumably wonder why that administrator couldn't just go and tell that manager to shut down his server.)
I do acknowledge that some compromises exist and that virtualisation in the broadest sense of the term recurs frequently, so that in the Debian environment an administrator could enable something like schroot, for example, but then again, I get the impression that if users have to ask for something like that, they may well not get it. In any case, I think it is absurd that when the bulk of the work done by a package manager could be delivered for arbitrary filesystem locations and for arbitrary users, one should be forced to reach for the virtualisation sledgehammer. What next? Running "make install" only puts things under /usr because one can always create another virtual machine?
GNU Guix launches Posted Nov 26, 2012 19:32 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
I'll point you several layers up in this thread
In a construction company, just because everyone is carrying tools that would let them break into the Dynamite Storage locker doesn't mean that you should just give everyone the key (or not bother to lock it in the first place)
Similarly, just because it's possible for a knowledgable person to bypass the restrictions on installing software on a machine doesn't mean that yhere are no cases where such restrictions make sense.
As far as I'm concerned, per-user application installs really don't make much sense nowdays. Almost all systems are single-user, so there is only the one user to install the app for. The few cases that remain where there are multiple users on a single system image are all cases where it's probably a bad thing to have users installing software (especially given how easy it is to have separate system images with either virtual machines ot containers to isolate the users when you do want them to share hardware)
GNU Guix launches Posted Nov 26, 2012 19:52 UTC (Mon) by apoelstra (subscriber, #75205) [Link]
> As far as I'm concerned, per-user application installs really don't make much sense nowdays. Almost all systems are single-user, so there is only the one user to install the app for. The few cases that remain where there are multiple users on a single system image are all cases where it's probably a bad thing to have users installing software (especially given how easy it is to have separate system images with either virtual machines ot containers to isolate the users when you do want them to share hardware)
Even on a single-user system, there are many "users" like apache, ftp, sshd, dbus, etc. And these programs often have security as a high priority, and would not like libraries being switched out underneath them.
So it's nice to be able to install applications and libraries in my own home directory, even though I'm the only human user of the system, just to avoid upsetting the rest of the system.
GNU Guix launches Posted Nov 26, 2012 21:07 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
the "users" like Apache, ftp, sshd, dbus, etc had better not be installing software packages for themselves.
If you want to not have these different things depend on a common set of libraries, you still don't need per-user installable packages, you just have a distro do static linking of libraries instead of dynamic linking (or you use chroot sandboxes or containers)
GNU Guix launches Posted Nov 26, 2012 22:39 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
If you had perfect foresight that would be a fine answer. It's hard to 'go back' and change the way things are set up when you find you need something a little different today.
GNU Guix launches Posted Nov 27, 2012 13:15 UTC (Tue) by pboddie (subscriber, #50784) [Link]
Enough with the dynamite analogy: I never suggested that people should be able to "blow up" their systems with full root access. Indeed, it's precisely this attitude - that wanting to do only a little more than currently possible is somehow the same as "wanting it all" - that undermines any discussion on such matters and drives people towards exactly the social and institutional workarounds I already described.
It's interesting to hear the claim that most systems - presumably Unix-related ones - are now single-user systems. Even if that is the case, giving people the ability to customise that environment without having to nag the administrative staff all the time is surely beneficial. Indeed, what has often happened is that people on those traditionally single-user Windows systems have been able to more or less install what they want, with all the accompanying consequences, whereas everyone else has had to make do with what they're given.
If people could just apt-get a package and have it installed in their home directory, it wouldn't necessarily affect the other users at all. Of course they could fill up the disk with a complete installation of GNOME or whatever, but that's what quotas are for. (Although I now expect to be told that quotas are archaic and people virtualise entire systems to get the same effect for this as well. If so, Linus Torvalds and the GNU project maintainers should consider slashing away at the realms of apparently dead code that no-one seriously uses any more.)
GNU Guix launches Posted Nov 27, 2012 16:00 UTC (Tue) by davidescott (guest, #58580) [Link]
> I never suggested that people should be able to "blow up" their systems with full root access.
We are both coming at this from different perspectives, so your example is installing Inkscape, and mine is installing Apache/Ruby/Haskell/GCC
Inkscape is a reasonably safe application to install because in the end the application either works or doesn't and what matters is the produced SVG file which is either compliant or non-compliant. I would have no objections to anyone installing that for one off interactive use.
Installing a web-server or a full-fledged programming language raises more concerns because it introduces something that has to be maintained into the future.
The problem is that the acceptability of applications is defined by the individual policy of the firm. Somehow the package manager has to classify packages in a manner that is consistent with the policy articulated by the firm, allowing the firm to then blacklist/whitelist individual packages as needed.
The problems are:
b) How granular is the classification to be? Are packagers really going to want to classify applications at the level of detail required by administrators trying to implement policy? Do they even know what administrators consider important? Do they agree?
c) Can any classification scheme possibly match policy? Policy might have more to do with use in practice than capability. Consider your Inkscape example. I might allow the occasional usage of Inkscape to create SVGs, but want to prohibit the scripting of Inkscape through python to automate the creation of charts for publishing. If Inkscape is white listed and python is a system dependency it may be impossible to express policy in a whitelist/blacklist at the package level, and some more conservative firms will then look at that and decide to blacklist everything.
d) Is policy defined or is it fuzzy? The firm may not know what to allow because they cannot anticipate all the crazy ways people might use the software they install. If the firm could actually articulate their policy clearly enough to implement as package management rules then the approval process would be much faster and might eliminate the need to even have this feature.
GNU Guix launches Posted Nov 28, 2012 13:29 UTC (Wed) by pboddie (subscriber, #50784) [Link] First of all, thanks for keeping the discussion productive and informative. I think that one of the fundamental differences in perspective is related to the following remark: The problem is that the acceptability of applications is defined by the individual policy of the firm. Somehow the package manager has to classify packages in a manner that is consistent with the policy articulated by the firm, allowing the firm to then blacklist/whitelist individual packages as needed. Here, we're talking about more than one organisational role. One matter is what people can do on their workplace machines to do their work in the most convenient and productive way possible without disturbing others or doing bad things to the workplace's systems. Another matter is whether the techniques used are sustainable and documented so that other people in the workplace can follow what was done. In the case of Apache, surely the way to deal with the possibility of someone installing it is to make sure that any instance of it will never be seen from any other computer, which is probably a policy employed in organisations where "high ports" are regarded as completely untrusted. The tools already exist to contain unprivileged users, mostly because that was the motivation for having multi-user/privilege systems in the first place. So it seems to me that forbidding package installation - recalling that I only advocate installation under non-root privileges - is a very coarse way of controlling what users do, and the extent of that control will rely on the existing measures, anyway. (Forbidding the installation of Ruby doesn't stop people from writing "bad" programs unless you take the shell away from them as well.)
GNU Guix launches Posted Nov 28, 2012 17:13 UTC (Wed) by davidescott (guest, #58580) [Link]
I don't see how we are ever going to agree, because we see something like "running apache on a high port on an internal desktop for internal business purposes" differently.
You view it as developer Joe just wanting to be able to run the server for his own use, and it cannot possibly harm anyone so long as the corporate firewall works.
Management may see it as (a) something that others may come to rely upon and when Joe leaves for another firm someone else has to take over requiring that the code be brought up to the appropriate standards or (b) an internal application that leaks data across business lines and fails to integrate with the standard security policies managed by the firm.
Similarly with installing Inkscape, it could become something that is integrated into a process without approval, such that nobody knows how to manage it when the installer leaves, or could expose the firm to legal risk down the road (those automated charts Joe creates with inkscape are deemed to be deceptive according to Regulation 142.6(a) subsection (iv) paragraph 3.14 which requires that all bar charts have a width of at least 22px). I personally don't like this attitude, but after working in a regulated industry I recognize that it exists.
You are also implicitly suggesting that every machine on the internal network run a firewall that blocks incoming packets on high ports. How many companies actually do this, vs just having a firewall at gateway? It could be a lot of work for network admins to customize the firewall rules to the individuals machine.
I'd also be curious to know how a company like Google handles this kind of situation. Certainly their staff is skilled enough to be able to run personal web-servers, but at the same time someone with a misconfigured server could leak data across the google network.
--------------------------------------------------
A lot of this audit stuff is ridiculous, and I think there is a tacit recognition that it is absurd. Saying that an employee went off an did something on his own without approval makes it possible for the corporation to avoid liability, whereas if you all them to apt-get install something its much less clear that they were violating policy in doing so.
GNU Guix launches Posted Nov 28, 2012 19:59 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
I assume that there would be a way that administrators could disable per-user package installation if wanted. I don't see how the *existence* of the feature is a problem in and of itself. I'd certainly like to be able to install different versions of the boost packages into a local directory so that I don't have to touch Boost.Jam umpteen times to test against everything from 1.44 to the latest release. Or try out the newest shiny (especially with things like newer mesa where if it screws up, I still have a fallback to rely on). without having to upgrade an entire distro (or install an ancient one for older versions).
I would like to have 10 compiler versions installed so that I can test everything with one machine instead of needing 10 VMs of various versions of distros to get those versions and installing things by RPM is a whole lot more reliable than me trying to replicate what is installed in those systems manually.
GNU Guix launches Posted Nov 28, 2012 21:23 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
The issue is that the main case for why this feature is needed is a very close overlap with the cases where it is very questionable due to the reasons mentioned above.
As far as installing multiple compilers, go read Rob Landley's notes of the fun he has doing cross compiles, specifically all the work he has to do to beat gcc into using the right version of things. It sure doesn't look like it would be nearly as trivial as "install multiple copies of gcc in different directories"
If I had to do that, I'd use debbootstrap to create chroot sandboxes with different versions installed in each one. You don't even need containers, let alone VMs.
GNU Guix launches Posted Nov 29, 2012 14:23 UTC (Thu) by pboddie (subscriber, #50784) [Link]
I do actually use debootstrap with chroot sandboxes precisely to be able to manage multiple software environments. However, this only works reliably for genuine chroots and not fakechroots, at least if you want to sample other distribution versions (mostly because of system library incompatibilities), and it gets to the point where you also need a newer kernel version to run significantly newer distribution versions. At that point, I actually use User Mode Linux, but there are plenty of root privilege obstacles that would prevent me from having such a sandbox if I didn't have root access.
Setting up chroot sandboxes isn't really so lightweight, but I suppose it is at the lighter end of the virtualisation spectrum in the broadest sense of the term.
GNU Guix launches Posted Nov 29, 2012 17:14 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I don't want to install old RPMs as-is; that way does indeed lead down into its own dependency hell. I would like to recompile Fedora 14 RPMs for my current machine and still be able to install it somewhere.
GNU Guix launches Posted Nov 29, 2012 18:00 UTC (Thu) by pboddie (subscriber, #50784) [Link]
I don't do things with RPMs, but if I wanted to build a Debian package for my current distribution version, I guess I'd go through the usual dpkg-buildpackage route (or use pbuilder if I had root access) after tweaking the package metadata. Since I only ever back-port things (and not that often given that I may choose to run them in a chroot), I don't know how much work would actually be necessary to forward-port a package, but quite possibly not that much.
Installing the package is another matter, though. Without root access, I'd have to hope that my fakechroot sandbox is up to the task, but given that it would be the same distribution version, the chances of that are a bit higher than they otherwise might be. I suppose that febootstrap would be able to deliver the same experience for Fedora, potentially not even needing fakechroot to do an initial bootstrap.
GNU Guix launches Posted Nov 29, 2012 17:20 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Hmm…installing a different GCC in macports looks like it just dumped it all in its own subdirectory. I'm not so interested in cross compilers, just different versions of various compilers.
I don't know why GCC would have problems with it unless you used the same $PREFIX for all of them. It's not like GCC would know to look anywhere other than its installation tree and possibly the system. Usually I use $HOME/misc/root/$name-$version as the prefix so that removing one is an rm -rf without having to rely on whatever (usually broken) uninstall mechanisms the project uses. LLVM is certainly happy being installed to $HOME/misc/root/llvm-3.2svn without being confused by the system version.
GNU Guix launches Posted Nov 29, 2012 17:06 UTC (Thu) by davidescott (guest, #58580) [Link]
We aren't objecting to the existence of the feature. If someone wants to implement it that is their right. What we are questioning is the marketability of the feature. It was initially described as a killer feature of Nix, but in my mind Virtualization looks a lot better for a number of different potential use cases. Other than shared hosting (which I don't have a particularly high opinion of to begin with). I'm genuinely curious what use case makes this the killer feature that really sells Nix/Guix.
GNU Guix launches Posted Nov 27, 2012 15:17 UTC (Tue) by lambda (subscriber, #40735) [Link] Your objections seem to be based on not understanding the Nix package manager. If a user installs a package under Nix, it's installed in its own environment, and does not affect what packages other users see or behavior of other packages. I guess that's what you call "containers (AKA VM-lite)", but it's not really the same thing; in fact, I would say both of those characterizations are wrong. A container isn't really "VM-lite", unless you want to call a modern operating system with separate users, memory protection, and preemptive multitasking "VM-lite" as well. A container is a way in which you can selectively isolate more resources, while sharing resources that still ought to be shared; it's the continuation of the idea of separate processes and memory protection, allowing you to apply isolation to more resources. And Nix differs from a container, since in a container, you either give the user their own root with nothing shared, in which case, from a filesystem perspective, sure, it's VM-lite; everyone has to install all of their own copies of everything. Or you could share certain directories like /usr, but then you wind up with problems updating the base system breaking your packages installed in your container. Nix works by building up a tree of package dependencies. Each package specifies the exact packages it depends on (the precise version and dependency tree, similar to the way Git refers commits by the SHA-1 of the current state and the SHA-1 of its ancestors), and packages are never replaced, new versions are installed in a new location. So a user can install local packages which depend on system packages, only using the extra space for what they specifically need; but if the base system updates, their packages will still depend on the old versions, causing them to stay around. Once the user updates their packages to newer version, depending on the new system libraries, the old versions will be GCed if no one depends on them.
GNU Guix launches Posted Nov 27, 2012 16:29 UTC (Tue) by davidescott (guest, #58580) [Link]
> Your objections seem to be based on not understanding the Nix package manager.
The objection is NOT that nix will somehow screw up the system by having conflicting packages. I'm objecting to the concept of user-installable packages, under the assumption that the package manager handles conflicts perfectly.
There are various objections (5 have been listed) the one closest to what you describe is that someone installs X to build Y. Initially this is fine because Y is a non-critical internal only application and a stop-gap measure until the real solution can be released. Of course Y morphs into something more and becomes a critical permanent external application and needs to be brought into compliance (moved to a secure server, audited, etc), and the approved systems are not capable of running the required X.
See http://us.thedailywtf.com/Articles/Excellent-Design.aspx for an example of this.
GNU Guix launches Posted Nov 27, 2012 17:17 UTC (Tue) by davidescott (guest, #58580) [Link]
After submitting I went back and rereading my comment and realized that you were responding to my response to phoddie's description of VMs as perverse sledgehammers.
You are correct that my previous comment is not correct with respect to how Nix operates. My point (poorly expressed) was that a package manager is either going to introduced a combinatorial explosion of potential conflicts or be VM-lite by supporting independent package installations.
I'm objecting to the suggestion that VMs are a perverse sledgehammer. I think they are a very good sledgehammer to quickly roll out lots of independently configured instances. If Nix+Containers can accomplish that while eliminating some duplication then VM-lite may be preferable to pure VM, but that has nothing to do with user-installed packages.
GNU Guix launches Posted Nov 28, 2012 13:39 UTC (Wed) by pboddie (subscriber, #50784) [Link]
To be fair, I use virtualisation in the broadest sense myself, but when you have package management systems like opkg which appear to be able to operate for unprivileged users in their own chosen areas of the filesystem, having to use "virtualisation" even at the level of maintaining separate chroot environments has to be seen as a kludge and not the product of two virtuous technologies coming together to "solve" an apparently unsolvable problem. If anything, it just pushes the complexity avoided by the somewhat overly conservative design decisions of the package management systems concerned onto some other activity instead.
|
|||||||||||||