You are not logged in.
Rationale
Dealing with the question which GNU+Linux distribution to install in a certain case can be quite a daunting task. One and possibly the main factor that often makes it unnecessarily time-consuming is that most distributions don't seem to offer a concise overview of what you can expect from them, so you could easily compare them. This is what websites like DistroWatch or Wikipedia's Comparison of Linux distributions are normally for. However, they tend to be out of date, potentially incorrect and may, on the one side, offer information that is largely irrelevant to the average user (e. g. "approximate number of pre-compiled packages" in the above-mentioned Wikipedia page) and, on the other, lack information that is relevant (e. g. the kernel version used by the distribution).
In an effort to provide such an overview for Devuan, I've drafted the following "Devuan fact sheet". So far, it includes information on everything I usually want to know about a GNU+Linux distribution. So, feel free to propose additions or removals. Also, the name is just a working title (which is why I've put it in quotes).
As I've already mentioned in the discussion on #devuan, the whole thing could probably be auto-generated by a script in the future, so it would require almost no maintenance.
"Devuan fact sheet"
Current stable version: 1.0
Code name: Jessie
Release date: 2017-05-27
Kernel version: 3.16.39
Init system: SysVinit
Package managment system: Advanced Package Tool (APT)
Package format: deb
Current ports ("Supported hardware architectures"): amd64, armel, armhf, i386 # not sure, if "armel" and "armhf" part is to be considered correct
Desktop Environments packaged: LXDE, MATE, Xfce # maybe provide version information
Available images (and their approx. sizes): DVD (4GB), CD (>650MB), NETINST (>270MB) # this is a bit tricky, since sizes sometimes differ quite a bit between architectures, also the embedded and live images aren't included here yet
++UPDATE++
As you can read below, the whole thing has been moved to gitlab: https://git.devuan.org/msi/devuan-at-a-glance
Also it has seen quite a bit of work by me and golinux and is now up for review. So, your comments and criticism are very welcome (here or on gitlab).
Apropos X11 and potential successors: I just read yesterday that in the early 2000's there existed a project called the Y Window System which was developed by a guy named Mark Thomas at London's Imperial College and intended as a potential successor to X11. The design documents are still available at http://www.imperial.ac.uk/pls/portalliv … 619743.PDF.
Development of the original project seems to have ceased in 2004, but there has been a continuation called DsY-Windows. They have a Sourceforge page stating the last update occured in May 2015. It seems, however, that no one is really working on that anymore, which is a bit strange given the bunch of problems that seem to exist with X11.
Also, some one at the Xorg Foundation has written down a few ideas about a potential "X12" system some time ago: https://www.x.org/wiki/Development/X12
Hi,
When I try to shutdown the system asks the root password.
How could I avoid this?
How are you trying to shut down? If you're working in a graphical environment, a reasonable login manager should solve the problem since it would normally be running with root privileges.
Alternatively, if you have sudo installed, you can also set up a rule in /etc/sudoers or create your own file in /etc/sudoers.d/ (which is probably the better way) and then use
sudo shutdown -h
You can configure sudo not to ask for your password, too.
But make sure you use visudo to edit the file and get a basic understanding of what's going on in /etc/sudoers if you don't know that already.
Ozi, this is not about missing packages. I'm not 100% sure about my following explanation, but it should be alright (i'm ignoring policykit here):
In the above case, the problem was that PCManFM was unable to communicate with gvfs (well, sort of). PCManFM and gvfs use D-Bus, a system for interprocess communication, to communicate with each other. Now, for things like communication between the file manager and gvfs in your X session, D-Bus uses per-user instances of its message bus deamon (visually speaking, one telephone network per user for the communication between the programs this user works with). If you just start X from the command line without further configuration, that message bus deamon won't be started. Therefore, PCManFM won't be able to call gvfs and ask it to mount a device. Putting
exec dbus-launch
into your ~/.xinitrc file instructs the xinit program to start that per-user d-bus deamon for the session and so provide means of communication between PCManFM and gvfs.
Also xfe does mount/umount.
Well, I'd be interested in how Xfe does that.
NOTE: MIXING DEVUAN RELEASE BRANCHES IS GENERALLY NOT ADVISABLE BECAUSE IT CAN EASILY BREAK YOUR SYSTEM! ADDITONALLY, THERE MAY BE CASES IN WHICH THE FOLLOWING STEPS WILL NOT COMPLETELY REVERT YOUR SYSTEM TO STABLE AND FURTHER FIXING ON A PER-PACKAGE BASIS WILL BE REQUIRED.
If you have installed packages from testing in Devuan stable and want to revert your system to a state in which it only contains packages from the stable branch, follow these steps.
1. Login as root, go to /etc/apt/prefrences.d/ and create a file named "force-stable" (or name it anything you like) there:
# cd /etc/apt/preferences.d/
# touch force-stable
Now, put the following lines into that file:
Package: *
Pin: release a=stable
Pin-Priority: 1001
Pinning the priority of stable to a value beyond 1000 will only allow packages from the stable branch to be installed on your system. Any packages from elsewhere, including backports and security upgrades (which come from a dedicated Devuan repository of their own), will be downgraded.
2. Upgrade your system:
# apt-get upgrade
In case this renders any packages obsolete, uninstall them with:
# apt-get autoremove --purge
3. Delete the file you created in /etc/apt/preferences.d/ or move it to another location, if you want to save it:
# rm /etc/apt/preferences.d/force-stable
or
# mv /etc/apt/preferences.d/force-stable /home/myself/good_spot
4. Deactivate the testing repositoriy in your /etc/apt/sources.list:
#deb http://de.mirror.devuan.org/merged/ ascii main
#deb-src http://de.mirror.devuan.org/merged/ ascii main
5. Update, re-upgrade, clean up
Now run
# apt-get update
to make apt aware of the new configuration.
As all security upgrades were lost in the downgrade above, you need to bring your system up to date by running
# apt-get upgrade
once again.
Finally (and optionally), wipe obsolete packages from your disk with
# apt-get autoclean
Thanks for the hint! However, I felt that line looked really complex for doing nothing but pull in settings from ~/.Xresources. And so did other people in the Arch Linux forums (see https://bbs.archlinux.org/viewtopic.php?id=208894).
Actually, it's enough to just put the following into your ~/.xinitrc (running order matters):
xrdb -load ~/.Xresources
exec dbus-launch --exit-with-session openbox-session
You could even omit "-load" since that is xrdb's default action. But that would make the whole thing look unnecessarily cryptic to me.
Btw, my ~/.Xresources file looks like this:
xterm*font: 9x15
xterm*geometry: 100x24
xterm*background: black
xterm*foreground: white
I'm marking this topic als solved. Explanations on dbus and policykit as well as other comments still welcome.
I've had the developer of udiskie take a look at all this. He suggested that it's not actually a problem with udisks2 but with some other element of PCManFM's mount procedure, possibly gvfs. He told me to try to mount and unmout removable devices through udisksctl without "org.freedesktop.udisks2.filesystem-unmount-others" in place in order to verify that.
As can be seen below, that worked seemlessly:
msi@moon:~$ udisksctl mount -b /dev/sdb
Mounted /dev/sdb at /media/msi/SONY.
msi@moon:~$ udisksctl unmount -b /dev/sdb
Unmounted /dev/sdb.
msi@moon:~$ udisksctl mount -b /dev/sr0
Mounted /dev/sr0 at /media/cdrom0.
msi@moon:~$ udisksctl unmount -b /dev/sr0
Unmounted /dev/sr0.
FWIW on my Devuan Jessie Xfce, I have both udisks2 and libsystemd0 installed but not libpam-systemd. Drives do not automount but do with a click on a right button menu option of the icon that pops up on my desktop.
I tried Devuan Jessie with a full installation of LXDE (except for a login manager) today. That didn't change anything for the better. You just can't unmount a CD without giving your root password.
So, what about gvfs then? Well, it uses dbus. Reading through various forum posts, I saw that some people have solved problems with accessing removable devices by creating an .xinitrc file containing
exec dbus-launch [window manager]
The manpage for dbus-launch reads:
"The dbus-launch command is used to start a session bus instance of dbus-daemon from a shell script. It would normally be called from a user's login scripts."
As it seems, gvfs uses dbus as an interface to communicate with other system processes that can then perfom actions like, for example, mount a removable device. However, just starting your X session with startx doesn't provide that interface per se. You have to explicitly request that within your .xinitrc file. For Openbox, it would have to look like this:
exec dbus-launch --exit-with-session openbox-session
This solves the problem, but it also brings a new one in that this configuration – for whatever reason – totally ignores the xterm settings (font size etc.) in my .Xresources file.
Thinkg about and trying to understand what dbus is, it crossed my mind that when there's a dbus interface for the X session, there's probably no need for all those policykit rules I've been amusing myself with lately. So, I shoved aside /etc/polkit-1/localauthority/50-local.d/10-removable_storage.pkla to see what happens. Well, nothing happens and everything works fine – if you count out the xterm issue.
If, maybe, someone could breifly explain dbus, policykit and their relation, that would really help.
If this is "in fact aligned with the reality of systemd", I must really have missed something.
I think you should really cool it with allegations of fascism and conspiracy. It's inappropriate. And there's nothing wrong with wanting to eat your cake and be happy. I do that every day.
Not getting anywhere near solving the problem, I installed Debian Jessie on a testing machine to see if the same issue would occur there. Well, it doesn't. Everything works fine with the set of policykit rules I had used in the first place and there is no need to allow "org.freedesktop.udisks2.filesystem-unmount-others".
This seems to be a systemd-related issue. In Debian Jessie, udisks2 depends on libpam-systemd as well as on libsystemd0; the Devuan fork doesn't. So, what now?
As for using SpaceFM as an alternative, I've just been told today on the project's official IRC channel that "development is dead".
I've now found a way to unmount CDs using a bit of a less insecure (though still unsane) configuration. Going through the list of available policykit actions for udisks2, I discovered that allowing "org.freedesktop.udisks2.filesystem-unmount-others" in addition to all the actions allowed in the setup I began with makes it possible to unmount CDs as well.
So, /etc/polkit-1/localauthority/50-local.d/10-removable_storage.pkla currently looks like this:
[udisks2 permissions]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.encrypted-unlock;org.freedesktop.udisks2.power-off-drive;org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.filesystem-unmount-others
ResultAny=yes
ResultActive=yes
ResultInactive=yes
The description for "org.freedesktop.udisks2.filesystem-unmount-others" reads: "Unmount a device mounted by another user". Therefore, this configuration will enable unprivileged users to unmount anything (if they are in the plugdev group), but that's it.
The question this inevitably leads to is: Why would a CD be mounted by another user than the one asking the file manager to mount it? The thing is that this doesn't even seem to be the case. When I check the list of mounted devices with mount after mounting the CD, I get this:
/dev/sr0 on /media/cdrom0 type iso9660 (ro,nosuid,nodev,noexec,relatime,user=msi)
When I delete "org.freedesktop.udisks2.filesystem-unmount-others" from the local authority file and then try to unmount a CD via udisksctl, this happens:
msi@moon:~$ udisksctl unmount -b /dev/sr0
==== AUTHENTICATING FOR org.freedesktop.udisks2.filesystem-unmount-others ===
Authentication is required to unmount HL-DT-ST DVDRAM GH22NS50 (/dev/sr0) mounted by another user
Authenticating as: root
Password:
Am I missing anything here?
I wonder how desktop environments like LXDE or Xfce solve this.
After tinkering with udisks2, udisks, udevil, SpaceFM and PCManFM for several hours on a testing machine as well as on my main system, installing and removing packages back and forth, I discovered that the solution to not being able to unmount CDs should be very simple. It's obviously about getting the policykit rules for udisks2 right in the local authority file in /etc/polkit-1/localauthority/50-local.d (which I've chosen to rename 10-removable_storage.pkla).
If I simply allow members of the plugdev group to perfom any udisks2 action, then I'm also able to unmount and eject CDs through PCManFM without any problem. To achieve this, /etc/polkit-1/localauthority/50-local.d/10-removable_storage.pkla needs to look like this:
[udisks2 permissions]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2*
ResultAny=yes
ResultActive=yes
ResultInactive=yes
However, allowing everything is never a good choice. In this case, allowing any udisks2 action to be performed by members of the plugdev group enables me to unmount system partitions as an unprivileged user. Though this isn't possible through PCManFM since it doesn't display the partitions of my hard drive as seperate devices, I can use the udisksctl commandline utility to do it. As an example, I unmounted and remounted my /boot partition:
msi@moon:~$ udisksctl unmount -b /dev/sda1
Unmounted /dev/sda1.
msi@moon:~$ udisksctl mount -b /dev/sda1
Mounted /dev/sda1 at /boot.
I was also able to force my in-use /home partition to be unmounted during normal system operation, just by adding the "-f" parameter. To fully comprehend the infernal security disaster created by the above, you might want have a look into the list of all udisks2 policykit actions that have now been unleashed to play with for anyone on the system (see https://udisks.freedesktop.org/docs/lat … ions-file).
So the question now is, which udisks2 rules have to be put into policykit's local authority file to enable normal users to handle CDs without enabling them to crash the system at the same time.
By the way, all of the above also works for Thunar.
On a side note, I can also confirm now that installing XDM has no part in making this work.
PS: Don't forget to install cryptsetup in case you want to (un)lock encrypted drives through the file manager.
Not sure what 'the standard way' means to you, but for example, the group name 'storage' is not listed at https://wiki.debian.org/SystemGroups. I suppose, that might not be normative for Devuan, since Devuan is not Debian, but to me it implies that polkit is not standard.
You are right about storage not being a standard group. But that's not connected to policykit. You could use the plugdev group instead. The storage group was part of the pre-systemd setup in Arch Linux, it's purpose being to grant "access to removable drives such as USB hard drives, flash/jump drives, MP3 players" and "enable the user to mount storage devices." (https://wiki.archlinux.org/index.php/Us … emd_groups) Thinking about it again, there's actually no reason to create the storage group at all. So, I deleted it and substituted "storage" with "plugdev" in /etc/polkit-1/localauthority/50-local.d/10-udisks.pkla.
Also, I found out that the kind of problems I was having can arise from starting X directly from a tty, which I normally do. There seem to be ways to fix this by creating a reasonably equipped ~/.xinitrc file. As my attempts to do that weren't successful, I simply gave XDM a shot. Et voilà, apparently this made things work. I then removed XDM with apt-get purge and also deleted ~/.xinitrc, since I don't normally need it. Surprisingly, (un)mounting and accessing USB drives through PCManFM and Thunar still worked flawlessly, which had me think that it doesn't actually have anything to do with XDM, which hadn't pulled any dependencies on installation.
So, now I was able to handle USB devices through PCManFM. What still didn't work, were CDs. Just as before, I was able to mount a CD but unable to unmount it. Also, CDs were being mounted to /media/cdrom0, which probably means they are not being handled by udisks2.
Then I tried SpaceFM and udevil. That totally worked. However, I needed to give apt "adwaita-icon-theme-", so it wouldn't pull a whole lot of stuff I don't need. The latter had already been an issue throughout the installation process of my Devuan system.
Any ideas on how to solve the CD unmounting problem in PCManFM? I'm not sure if I want to go with SpaceFM. I'm used to working with PCManFM and it was able to handle CDs correctly on very much the same setup in Debian Jessie.
PS: I think there should be a removable media guide for minimal desktops.
What was wrong with using pmount/pumount ?
Well, I don't know how to make PCManFM use pmount for (un)mounting removable media. Also, udisks2 in conjunction with polkit seems to be sort of the standard way to handle this. I really like the per-user mount points feature in udisks2, too.
I'm having trouble managing access to removable media for normal users on Devuan Jessie.
I first installed Devuan without any graphical user interface and then built on that. As I didn't install a full-featured desktop environment (using stand-alone Openbox), removable media access for normal users is not handled correctly out of the box and should be manually configured through polkit. The question is: How?
Without further configuration, I'm unable to mount external USB drives through my file manager (PCManFM/Thunar). I can, however, mount a CD-ROM, but have no permission to unmount it. It is also possible to mount USB devices through the file manager with usbmount. But unmounting still doesn't work then and I would rather not use usbmount.
What I want is this:
enable normal users to mount/unmount removable media through the file manager using udisks2 on the basis of a reasonable polkit rule applying to the "storage" group (which I've already created using addgroup)
mount devices to /media/[current_user]/[label] (which is what udisks2 does)
I'm already able to (un)mount removable USB devices with correct file permissions using udisksctl via the command line. But I always have to give my root password. So, this all comes down to a permission problem and writing the correct polkit rule.
Drawing on the info at https://github.com/coldfix/udiskie/wiki … #policykit, I created a file in /etc/polkit-1/localauthority/50-local.d, named it 10-udisks.pkla and put the following lines into it:
[udisks2]
Identity=unix-group:storage
Action=org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.encrypted-unlock;org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.power-off-drive
ResultAny=yes
Unfortunately, after rebooting the machine, nothing has changed. What could I be doing wrong?