
JuNest: Arch Linux-based distro that runs on any Linux OS, without root access - da02
http://fsquillace.github.io/junest-site/
======
romwell
JuNest is what made our department computers usable for me. With it, I could
run my favorite TeX editor (we don't have root access on these machines).

On a philosophical note, I second vortico's question of why common Linux
distros require root access to be at all usable. In particular, how did it
come to not being able to install a package without sudo?

I could download something, compile it, and run it, but not install from a
package. It doesn't make sense to me. If I can run it, I should be able to
"install" it locally, whatever the word "install" means (obviously, it
wouldn't mean writing to directories to which I don't have access otherwise).

JuNest simply proves this point.

~~~
0x8BADF00D
It's only certain package managers. For instance, pkgsrc and portage don't
require root access.

~~~
romwell
The "certain package managers" happen to be "every single package manager I've
encounter on a system I don't own".

I'll be content in knowing the history of "apt-get install" requiring sudo.

There's is this thread, but I don't understand how nobody in charge of
anything ever figured this all of that this design is bollocks if you want to
have true multi-tenancy on a system.

------
jitl
See also:

\- Nix: purely functional package manager that runs on multiple distros. 7/10
awesome ideas but difficult to work with.

\- Guix: like Nix, but with Guile Scheme, and different packages. Seems to
require system-wide installation and a daemon; also burdened with “freedom”.
??/10 haven’t tried it, but sounds iffy.

\- Linuxbrew: Linux port/fork of the popular Homebrew package manager for
macOS. 4/10 same problems as Homebrew itself.

\- Gentoo Portage Prefix: build and run Gentoo packages in a $PREFIX, without
root and on many different OSs. ??/10 haven’t tried it.

~~~
IMTDb
I am curious to know what are the problem of homebrew itself ? As a generic
user who has never done anything really complex with it, homebrew is a joy, it
has never failed me.

~~~
barrkel
Typically the problem areas would be in versioning of dependencies (in
particular, resolving conflicting version requirements for different packages,
where dependencies form a DAG rather than a tree) or around install hooks
(where installation / removal can't be represented simply by existence /
absence of whole files on the filesystem).

------
vortico
I use this at work and it's great if you don't have root access but still want
to install packages. (Why do you need to be root to install packages locally
on all distros anyway??) The Windows equivalent is MSYS2, where you have a
POSIX shell, pacman, and many packages thanks to the active maintainers.

~~~
jhasse
> Why do you need to be root to install packages locally on all distros
> anyway??

On most distros you just can't install packages locally.

On Fedora you can install packages globally without root btw: Try `pkcon
install pidgin` for example.

------
jcelerier
Junest is so useful if your project requires recent compilers or libs and your
contributors are under some old Debian Stable or Ubuntu.

------
ciconia
Would this be a viable alternative to containers?

~~~
the8472
from the documentation it sounds like it uses namespaces where available, just
like containers. chroot otherwise.

~~~
nerdponx
I was actually wondering what advantage this has over a container or chroot.
The answer is that it actually is one of those under the hood?

~~~
d--
I've tested JuNest extensively (with the idea of getting new gcc compiler
features on a cluster running an old red hat version).

Unfortunately, JuNest adds a lot more overhead than containers. Specifically,
when it comes to high-throughput network applications. At 10GBit an
application running on JuNest used several cores at 100%, while without JuNest
(underlying red hat) the app was at 10% cpu load (network i/o bound).

All that load was due to PRoot.

~~~
da02
Have you tried with Linux namespaces instead of PRoot?

[https://github.com/fsquillace/junest#linux-namespaces-
based](https://github.com/fsquillace/junest#linux-namespaces-based)

------
whalesalad
So is this a form of usermode linux? I'm not enough of a linux wizard to
understand linux-on-linux, chroot, etc...

~~~
traverseda
This uses systemd-containers, but can fall back to using a chroot, which
requires root.

Usermode linux involves running a linux-kernel as just another piece of
software under linux. By telling software to access the usermode linux, you
can give it a different "view" of the system. That linux kernel process must
communicate with the real-kernel, doing things like forwarding network traffic
to the "real" kernels network devices. It introduces overhead.

A chroot interrupts one system call (or set of system calls?), making any
program you call think "/" is a different directory. It literally changes
root. That being said, all it changes is where programs think the root dir is.
If you have software in the chroot that runs as root, it actually runs as root
on your entire system. It can do things like load custom kernel modules. It
can't break out of the chroot, chroots aren't a security feature.

Containers, like systemd-nspawn, use cgroups along with a more-aggressive
chroot-like thing, that gives programs a different view of all system calls,
not just calls to the filesystem. This means you can run software as "root" in
a container without privilege escalation.

Of course it doesn't need to be a full container. Firejail can use those same
mechanisms to do things like isolate just your web browser.
[https://firejail.wordpress.com/](https://firejail.wordpress.com/)

------
agumonkey
I used to use systemd-nspawn with a simple distro subtree.

~~~
0x006A

        $ systemd-nspawn
        Need to be root.

~~~
agumonkey
oh that's why it doesn't work anymore

~~~
lima
It does if your kernel has userns enabled.

~~~
wyldfire
Are there any distros who ship with that enabled in the default config? (or
plan a future release configured like that?)

