# Maintainer: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: Tom K <tomk@runbox.com>
pkgname=pmount
pkgver=0.9.3
pkgrel=1
pkgdesc="mount removable devices as normal user"
url="http://www.piware.de/projects.shtml"
depends=('sysfsutils' 'bash')
source=(http://www.piware.de/projects/$pkgname-$pkgver.tar.gz)
build() {
cd $startdir/src/$pkgname-$pkgver
make PREFIX=/usr || return 1
make PREFIX=/usr DESTDIR=$startdir/pkg/ install
}
I won't be putting this in the AUR, as I'm sure tpowa will pick up the out-of-date flag.
]]>#!/bin/sh
# This is a setup script to add plugdev group (gid 404) and ivman user
# (uid 107, group plugdev). Use at your own risk!
# Check, that we are root:
if [ `id -u` != "0" ] ; then
echo "You're not root. Permission denied."
exit 1
fi
# Add 'plugdev' group:
echo "Adding plugdev group (gid 440)."
groupadd -g 440 plugdev
# Add ivman user:
echo -n "Enter your mount dir (/media): "
read mount_dir
if [ $mount_dir = "" ] ; then
mount_dir="/media"
fi
echo "Adding ivman user (uid 107, gid 440)"
echo "ivman:x:107:440:ivman:${mount_dir}:/bin/false" >> /etc/passwd
# Change permissions for mount points:
mount_points=`ls $mount_dir`
for point in $mount_points ; do
echo "Changing $mount_dir/$point permissions."
chmod 775 $mount_dir/$point
chown ivman $mount_dir/$point
chgrp plugdev $mount_dir/$point
done
# Echo the success:
echo "Ivman set-up complete!"
For *sh newbies:
It creates plugdev group with gid 440, ivman user with uid 107, and adds it to plugdev group. Also it changes permissions, so the ivman can mount devices. After thisc script is run ivman works almost perfectly.
When I sayed almost I meant, that ivman now needs newer version of pmount, to mount devices for specific uid (or else mounted filsystem will *only* be accessible for ivman itself). I could not find newer pmount anywhere in pacman , and making PKGBUILD for it is a bit tricky, so I cannot help here anymore. I just removed pmount from pacman, and installed it from source, all for the sake of automounting...
:: Edit:
Heh, Iphitus, you were waay faster typer than I am.
In this case, the problem is that ivman needs the user 'ivman' and the group 'plugdev'
to add them,
useradd ivman
groupadd plugdev
now ivman runs and it spits this out.
manager.c:580 (ivm_device_mount) Refusing to mount /org/freedesktop/Hal/devices/volume_uuid_08c59edd_fa2b_442b_a147_240e5f89b895 because I am a system-wide instance of Ivman but pmount does not accept -u <umask>, so if I mounted, it would be accessible from the ivman account only. Upgrade pmount or start an instance of Ivman as the user you wish devices to be accessible from.
which is because Arch's version of pmount is out of date. Latest is 0.9.3, arch has 0.7.1.
I'm now filing bugs for the ivman bug, and marking pmount out of date.
Issue solved.
]]>
http://bbs.archlinux.org/viewtopic.php? … t=hal+dbus
It's being worked on: http://bugs.archlinux.org/index.php?do= … ments#tabs
We may expect a working package
later today
Does someone have same problem?
(sorry for the bad english)
]]>See my previous post, for reasons why I think this is not true. So can anyone contact gentoo forums (I think that's the place), or someone with knowledge what is 'plugdev' group, and ask what it does so we can create one in Arch ( maybe a post-install script for ivman would be nice), and in that case, downgrading hal would not help, also the permission problem I mentioned is a perfect explanaition, why ivman is working as user (it simply does not like root anymore ). And Dreameen, please do not take this as a flame or something of that kind.
First of all, why would I take your posts as a flame? I appreciate the research you've done and thank you for the accurate information you gathered. It's something I should have done myself to avoid the confusion in the first place.
Secondly, I'm sorry to say this but ivman won't run as root from a very simple reason...It's one of its "features" implemented during the trasition from 0.5 to 0.6. So, simply speaking, our resistance is futile:lol:
I was devastated when I read this in ivman change log:
Changes from 0.5->0.6
* Now use pmount (http://packages.debian.org/unstable/utils/pmount) instead of mount - no need to have any entries in your fstab for removeable devices or even CD/DVD drives, and no need for fstab-sync
* HAL 0.5 support (meaning ACPI support :-)
* Hardware 'condition' support (e.g. run a command if your processor overheats, if you push the power button etc.)
* No longer runs as root
* Video DVD unlocking problem solved
* More stable :-)
I'd like to thank everyone for the feedback on this issue. We would all avoid the unnecessary confusion, if arch provided changelogs, concerning the major changes in an updated package. On the other hand I know it's a time consuming task, to hunt all the relevant info concerning an update of a program. The lack of CHANGELOGs in some projects doesn't make the job any easier. I don't know how it's done in other distributions, but from what I've read, arch devs are planning to incorporate the idea of changelogs into ABS. Time will tell...
As for now, the ivman rc.d script script should be modified to run as non-privilaged user. I'll have a look at the script and see if I can fix it up.
]]>Scenario#1. Remove ivman from daemons in rc.conf and add it to your wm startup script. Ivman should create the appropriate configuration files in your home directory and run just fine.
Scenario#2. Downgrade hal to its previous ver. and see if ivman works for you.
See my previous post, for reasons why I think this is not true. So can anyone contact gentoo forums (I think that's the place), or someone with knowledge what is 'plugdev' group, and ask what it does so we can create one in Arch ( maybe a post-install script for ivman would be nice), and in that case, downgrading hal would not help, also the permission problem I mentioned is a perfect explanaition, why ivman is working as user (it simply does not like root anymore ). And Dreameen, please do not take this as a flame or something of that kind.
]]>hald --verbose=yes --daemon=no
I get lots of permission-denied-like errors (full file is here:
<snip>
2394: managed primary='comment=managed'
2394: managed secondary='kudzu'
2394: using temporary file '/etc/.fstab.hal.2'
2394: Could not open temporary file for writing in directory '/etc': Permission denied
2394: Releasing advisory lock on /etc/fstab
2394: Lock released
2394: fstab-sync exiting; --clean udi=/org/freedesktop/Hal/devices/computer
<snip>
21:56:53.461 [I] blockdev.c:365: Probing PC floppy /dev/fd0 to see if it is present
2402: 21:56:53.462: probe-pc-floppy.c:73: Checking if /dev/fd0 is actually present
2402: 21:56:53.462: probe-pc-floppy.c:78: Could not open /dev/fd0
<snip>
21:56:53.464 [I] blockdev.c:392: Probing storage device /dev/hdc
2403: 21:56:53.466: probe-storage.c:144: Doing probe-storage for /dev/hdc (bus ide) (drive_type cdrom) (udi=/org/freedesktop/Hal/devices/temp/66) (--only-check-for-fs==0)
2403: 21:56:53.466: probe-storage.c:157: Doing open ("/dev/hdc", O_RDONLY | O_NONBLOCK)
2403: 21:56:53.466: probe-storage.c:160: Cannot open /dev/hdc: Permission denied
<snip>
21:56:53.469 [I] blockdev.c:392: Probing storage device /dev/sda
2404: 21:56:53.470: probe-storage.c:144: Doing probe-storage for /dev/sda (bus scsi) (drive_type disk) (udi=/org/freedesktop/Hal/devices/temp/68) (--only-check-for-fs==0)
2404: 21:56:53.470: probe-storage.c:157: Doing open ("/dev/sda", O_RDONLY | O_NONBLOCK)
2404: 21:56:53.470: probe-storage.c:160: Cannot open /dev/sda: Permission denied
<snip>
And, as far, as I can see, '--retain-privileges' option is used for something related to permissions, because help says
Run as normal user instead of root (calling of external scripts to modify fstab etc. will not work run as root)
Anyways, when hald is run with '--retain-privileges' option it does not spit out any strange messages about permissions. As far as this parammeter goes, I think it is a good thing.
Next, D-Bus '--system' option:
--system
Use the sandard configuration file for the systemwide message bus.
This is not something strange also. So I think these options are not strange at all, as Dreameen sayed.
Also, I think I know why ivman is possibly is not working, I get these errors, when I run
ivman --nofork --debug
as root:
ivman 0.6.4, http://ivman.sourceforge.net
Compiled against HAL 0.5.x or later
Running in system mode
manager.c:493 (ivm_run_command) Running: echo 0 > /proc/sys/dev/cdrom/lock
daemonize.c:139 (dropPrivileges) Group 'plugdev' does not appear to exist!
manager.c:944 (main) Couldn't drop privileges to ivman:plugdev, exiting!
So, I think the problem is with something related to permissions and 'plugdev' group. I do not know what 'plugdev' group does, so I cannot comment any further. I hope this helps someone to figure this out further (I really need some sleep, as it's late evening and I've slept only for 4 hours last night).
]]>/usr/sbin/hald --retain-privileges
for our misfortune. Sth got b0rked with the privileges and ivman can't start as root anymore. In the current situation there's nothing we can do but wait for the update of ivman, which hopefully will deal with this problem. Still, if you need to get ivman running, there are 2 options:
Scenario#1. Remove ivman from daemons in rc.conf and add it to your wm startup script. Ivman should create the appropriate configuration files in your home directory and run just fine.
Scenario#2. Downgrade hal to its previous ver. and see if ivman works for you.
That's all I can say, for now...
]]>From my understanding, here's what happened: kdebase got updated, changing the way dbus&hal are started, that would explain the new options being passed to dbus&hal.
Ok... Why should I suffer from KDE, when I even do not use it? :shock: K* is in my way too frequently these days, even if not installed.
Ugh...Then it's definitely dbus&hal upgrade. Have you also noticed strange options passed to dbus/hal? Try grep'ing 'ps aux' for both and see what happens.
Ok. I grep'ed for those two:
ps aux | grep dbus:
nobody 3203 0.0 0.4 2092 1092 ? Ss 20:46 0:00 /usr/bin/dbus-daemon --system
ps aux | grep hal:
root 3225 0.0 0.9 3852 2444 ? Ss 20:46 0:00 /usr/sbin/hald --retain-privileges
root 3230 0.0 0.2 1896 688 ? S 20:46 0:00 hald-addon-acpi
root 3241 0.0 0.2 1900 700 ? S 20:46 0:00 hald-addon-storage