Re: Installing debs in ~user/ or /usr/local?
Alexander Hvostov [EMAIL PROTECTED] writes: The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. you may be interested in http://user-mode-linux.sourceforge.net/ Goodbyte, Gerd. -- Gerd Flaig Technik[EMAIL PROTECTED] Bei Schlund + Partner AG Erbprinzenstr. 4-12 D-76133 Karlsruhe
Re: Installing debs in ~user/ or /usr/local?
Alexander Hvostov [EMAIL PROTECTED] writes: The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. you may be interested in http://user-mode-linux.sourceforge.net/ Goodbyte, Gerd. -- Gerd Flaig Technik[EMAIL PROTECTED] Bei Schlund + Partner AG Erbprinzenstr. 4-12 D-76133 Karlsruhe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 22:35:58 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 05:47:21PM -0700, Alexander Hvostov wrote: On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: You should look into the S/390 port. The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. Hardware support is what is necessary to do what you described (in your previous message) at this time. What you described above sounds more like user-mode Linux. That's what I was describing. I had forgotten the name. Thanks! Regards, Alex.
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 02:15:58PM -0700, John H. Robinson, IV wrote:
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote:
workaround: just extract the data.tar.gz where you want it.
dpkg-home () {
[ $1 ] || { echo usage: $0 deb_to_install.deb [dir_to_install]
return 1 }
( cd ${2:-$HOME}
ar p $1 data.tar.gz | tar xzf - )
}
Or simply:
dpkg --extract deb dir
--
- mdz
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote: I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. In the Hurd, any user can boot a sub-Hurd system off a root filesystem image. (root means root filesystem, has nothing to do with the user root). In this sub-Hurd, it appears that the user has indeed control over a new instance of the Hurd operating system. The root filesystem can contain different software than the default system. From the default system, the processes run under the id of the user, but within the sub-Hurd, the user can acquire super-user privileges (uid 0). No permissions leak outside the sub Hurd. sub-Hurds can be nested of course. There is currently no virtualization implemented: All direct kernel accesses (hardware access etc) are simply forwarded to the systems kernel. However, the kernel is used for few things: As a microkernel based system, most of the functionality lives in user space kernels (which are duplicated in the sub Hurd). However, the boot process (the command used to boot the sub-Hurd) can intervene such kernel calls and virtualize them. This is something that interested people can work on. Indeed, you can implement whatever functionality you want. Again, systems security is strictly preserved by the default servers (modulo bugs ;). For that to work, you'd also need to set up a base system for each and every developer. That would waste a lot of disk space in a hurry. Perhaps copy-on-write file links would do the trick here, allowing root to keep a central repository of a prototypical base system, and allowing each developer to change it at will, For the Hurd we plan something called shadowfs. shadowfs will allow to stack filesystems in a single view. For example, you could join a read-only ext2fs filesystem and a tmpfs (in RAM) over it. Files in the tmpfs would shade the underlying ext2fs files, and new files would be created in the tmpfs, too. This way you get the copy-on-write trick you imagined. But that's not all. Ideally, such a shadowfs implementation would merge multiple filesystem trees, for example the system tree (ro) plus a user provided root filesystem. Then you can use this shadowfs to boot a sub-Hurd from, running from the default system usually but running from your files where they exist. This way you can test new servers in the sub Hurd with minimal cost. Oh, did I mention that all sub Hurd processes appear in the parents sub Hurd process table? This way you can attach gdb to them (from the outside) and debug them like any other process (even system-critical servers). Of course, if the sub Hurd crashes, the parent systems are not affected. but without wasting disk space unless something actually changes. Of course, that means big changes in the kernel's VFS code and possibly elsewhere, but copy-on-write links would be way cool for other reasons as well[1-2]. In Linux, yes. This would be close to impossible to implement securely without rewriting major parts of the kernel (possibly all). The Hurd provides the substantial features and design paradigms today (there are bugs, and there are missing features like full virtualization and shadowfs, but booting a sub Hurd for example works). [3] I understand Microsoft has done something like that in one of their operating systems or another. It was on Slashdot a while back. Most people said that what they `invented' are really just symlinks, but the major difference is that they're copy-on-write, whereas writing to a symlink on Unix will write to the file pointed to, but overwriting a symlink will overwrite the symlink, not the file pointed to this; is a pseudo-copy-on-write behavior, but not real copy-on-write like what MS did. Of course, they attached some lame marketroid buzzword TLA to it, but `copy-on-write link' works for me. ;) If you want such a thing, you can implement this as a Hurd filesystem server and run it as a user. You don't need to recompile, install and boot a new kernel. You just attach your server to some directory (mount if you want), and go. You'd probably violate some POSIX requirements with such a thing, but you don't need to limit yourself to it. The Hurd is a POSIX system in its default configuration, but the idea of the Hurd is that any user can extend the system in such ways you describe (and others) without asking anyone. For the far future, giving shadowfs, I'd be interested in a simple packaging system which allows to install multiple version of a single package, and which allows users to install packages. Basically, users packages would be mirrored over the root filesystem with shadowfs, and a sub Hurd
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: Hi all, maybe it is a stupid question, but can debian packages be installed in other places than / ? It is not a stupid question, IMHO. Unfortunately, I believe the answer is not in general. One of the problems is that .debs tend to install config files in /etc. I would suggest a search of the -devel archives, as this has come up at least once in the past year or so. I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? I think it is desirable, but I think it requires non-trivial changes to several bits of the packaging system. If you do the search of the archives, you might post a summary of what you find, to refresh our memories. -S
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: maybe it is a stupid question, but can debian packages be installed in other places than / ? I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? Debian packages require root privileges for installation. While you could unpack a .deb in your home directory and use the files in it, you would lose most of the advantages of using a packaging system (file tracking, autoconfiguration, etc.). If you use it this way, a .deb is no better than a .tar with binaries in it. I suppose you could install most simple .debs in a chroot environment where you owned everything, but many packages (notably those which run daemons, cron jobs, etc.) expect to be able to perform tasks as root. That said, .debs _are_ a good addition to .tar.gz for distribution. This is what Debian developers (in general) do: create and distribute .debs. -- - mdz
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote:
Hi all,
maybe it is a stupid question, but can debian packages be installed in other
places than / ?
i was thinking about this myself. i suppose in theory it is possible,
and the data.tar.gz has all the files that are installed, relative to
the root. the other peice is the control.tar.gz, which contains all the
maintainer scripts. and other miscleneously.
the problems i see with non-root:
suid/sgid binaries would lose those bits, and some functions of
maintainer scripts would fail (such as update-menus and update-rc.d)
also, /var/lib/dpkg/status and friends could not be updated.
workaround: just extract the data.tar.gz where you want it.
dpkg-home () {
[ $1 ] || { echo usage: $0 deb_to_install.deb [dir_to_install]
return 1 }
( cd ${2:-$HOME}
ar p $1 data.tar.gz | tar xzf - )
}
-john
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote: One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. You should look into the S/390 port. -- - mdz
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: maybe it is a stupid question, but can debian packages be installed in other places than / ? You could try the --root=dir, --admindir=dir or --instdir=dir options to dpkg. But I think that maybe this is not what you really want. I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? If the Makefile in the original source provides this functionality, then that is convenient to use in the Debian package source's debian/rules Makefile to install the binaries into the package build directory. Related to this is the --prefix option that can be given to the typical configure script in the original sources. If you don't specify that option when you ./configure, it usually defaults to /usr/local. Debian packages are generally spoken configured with --prefix=/usr. If user egon wants to install into his home directory, he should run configure the source with --prefix=/home/egon. After building the program, doing a make install will put all the files somewhere in /home/egon. Also, the programs that are installed there will look for their settings under /home/egon instead of /etc. This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Download package sources for your own rebuilding is just as easy as downloading the prebuilt .deb packages. Just add a deb-src line to your /etc/apt/sources.list file for every deb line it already has. After you apt-get update, you can cd into a work directory and type: apt-get source somepkg Then, do a cd somepkf-* and look around in the various README, INSTALL and other textfiles. There is a directory debian/ which contains some maintainer files, one of which is the rules file. This is a Makefile that contains the rules to build the source for Debian and to create the .deb package. It gives you a very efficient way to find out if there are any special tricks needed to compile the source. Now you can run ./configure --help, ./configure [options], make and make install. Is this possible? This is how it used to be before there was Debian ;-) Cheers, Joost
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote: One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. You should look into the S/390 port. The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. Regards, Alex.
Re: Installing debs in ~user/ or /usr/local?
On Sat, May 05, 2001 at 05:47:21PM -0700, Alexander Hvostov wrote: On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: You should look into the S/390 port. The S/390 port is hardware specific. For obvious reasons (how many Debian machines are S/390s?), this is inadequate. And anyway, I was referring to a Linux kernel in a process (ie, it behaves just like any other program, albeit rather large), not two Linux kernels running separately, which is what I understand the S/390 port does. Hardware support is what is necessary to do what you described (in your previous message) at this time. What you described above sounds more like user-mode Linux. -- - mdz
Re: Installing debs in ~user/ or /usr/local?
On Sat, 5 May 2001 16:48:05 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote: maybe it is a stupid question, but can debian packages be installed in other places than / ? I know that when the package is compiled the Makefile has a $DESTDIR attribute, but is this preserved in the deb package? This issue came up when i tried to convince someone that debian packages are a good addition to tar.gz for distribution... but one argument he gave, was the question if non-root users could install debian packages? Is this possible? Debian packages require root privileges for installation. While you could unpack a .deb in your home directory and use the files in it, you would lose most of the advantages of using a packaging system (file tracking, autoconfiguration, etc.). If you use it this way, a .deb is no better than a .tar with binaries in it. I suppose you could install most simple .debs in a chroot environment where you owned everything, but many packages (notably those which run daemons, cron jobs, etc.) expect to be able to perform tasks as root. That said, .debs _are_ a good addition to .tar.gz for distribution. This is what Debian developers (in general) do: create and distribute .debs. One could use fakeroot to create a sort of virtual machine, in which regular users can install packages as they please, but fakeroot doesn't support chroot (yet?), and I'm beginning to think a better solution would be an operating system within an operating system, and let the user play in her `own' system, and while it for all intents and purposes seems to be running on bare metal, it really is a virtual machine. That would be quite fantastic for doing normally privileged operations without a security risk, though. This could also be useful for Debian developers. This way, they could not only develop their packages on Debian machines (on which they don't have root), but also test them. I imagine quite a few packaging bugs in unstable would be wiped out that way. ;) For that to work, you'd also need to set up a base system for each and every developer. That would waste a lot of disk space in a hurry. Perhaps copy-on-write file links would do the trick here, allowing root to keep a central repository of a prototypical base system, and allowing each developer to change it at will, but without wasting disk space unless something actually changes. Of course, that means big changes in the kernel's VFS code and possibly elsewhere, but copy-on-write links would be way cool for other reasons as well[1-2]. Has anyone heard of an effort to do something like that?[3] [1] As some of you may notice, Quake 2 demands that it run in a directory with _all_ of its data files -- some of which normal users may change (eg, baseq2/config.cfg), and some of which normal users will probably never change, but might (eg, baseq2/pak?.pak). As it's done now, symlinks are created to files users are unlikely to change, and files users are likely to change are copied. With copy-on- write links, all files would be copy-on-write links, and the user can change any file, without wasting any more disk space than actually necessary. [2] The files in /etc/skel that get copied to new users' home directories might be changed by root from time to time, for whatever reason. Not all users are knowledgeable enough to change them, and of those who are, only some understand that they need to remove a symlink and copy the source file and edit that. With copy-on-write links, `adduser' would simply create copy-on-write links to the files in /etc/skel in a new user's home directory, and that new user can play with those files if they wish, and if they don't, they'll automatically receive updated versions of those files whenever root changes them in /etc/skel. [3] I understand Microsoft has done something like that in one of their operating systems or another. It was on Slashdot a while back. Most people said that what they `invented' are really just symlinks, but the major difference is that they're copy-on- write, whereas writing to a symlink on Unix will write to the file pointed to, but overwriting a symlink will overwrite the symlink, not the file pointed to; this is a pseudo-copy-on-write behavior, but not real copy-on-write like what MS did. Of course, they attached some lame marketroid buzzword TLA to it, but `copy-on-write link' works for me. ;) Regards, Alex.
