Re: [gentoo-user] autofs for a symlink - howto
On 02/24/2019 06:26:51 PM, Helmut Jarausch wrote: Hi, I have a lot of symlinks in my home directory like $HOME/Python -> /Src/Python Now, I'd like to not mount /Src on default. How can I set up my system (using autofs ?) to automatically mount /Src if such a symlink is accessed like cd$HOME/Python Since I didn't find a similar configuration on the net, I've come up with the following solution (after some trial and error) First, I've replaced all symlinks by empty directories of the same name. My /etc/autofs/auto.master contains (the only uncommented line) /-/etc/autofs/auto.local and /etc/autofs/auto.local contains, e.g. /Src -fstype=ext4,exec,suid,noatime :/dev/sdc3 /home/jarausch/Python -fstype=bind,exec,suid,noatime :/Src/Src/Python I hope this helps others, Helmut
Re: [gentoo-user] autofs for a symlink - howto
On 2/24/19 10:26 AM, Helmut Jarausch wrote: How can I set up my system (using autofs ?) to automatically mount /Src if such a symlink is accessed like cd $HOME/Python Many thanks for a hint, Review some of the automount tutorials. They will be geared towards NFS, but the same methodology should work for what I think you're wanting to do. From memory (I don't have a system handy that I can check) autofs / automount (it goes by different names) has it's base config file, and a few files that are included for various examples. You'll likely want to add another included file that specifies the paths that you want to automount. As a bonus, automount will unmount the paths after a period of inactivity.
[gentoo-user] autofs for a symlink - howto
Hi, I have a lot of symlinks in my home directory like $HOME/Python -> /Src/Python Now, I'd like to not mount /Src on default. How can I set up my system (using autofs ?) to automatically mount /Src if such a symlink is accessed like cd$HOME/Python Many thanks for a hint, Helmut
Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd
On 12/09 12:04, Mike Gilbert wrote: > On Sat, Dec 9, 2017 at 11:54 AM, wrote: > > On 12/09 06:27, Alexander Kapshuk wrote: > >> On Sat, Dec 9, 2017 at 6:03 PM, wrote: > >> > Hi, > >> > > >> > autofs-5.1.3 fails to compile: > >> > solfire:/root>emerge -v autofs > >> > > >> > These are the packages that would be merged, in order: > >> > > >> > Calculating dependencies... done! > >> > [ebuild R] net-fs/autofs-5.1.3::gentoo USE="libtirpc -dmalloc > >> > -hesiod -ldap -mount-locking -sasl" 0 KiB > >> > > >> > Total: 1 package (1 reinstall), Size of downloads: 0 KiB > >> > > >> Verifying ebuild manifests > >> Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo > >> Failed to emerge net-fs/autofs-5.1.3, Log file: > >> '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log' > >> Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, > >> 0.88 > >> > * Package:net-fs/autofs-5.1.3 > >> > * Repository: gentoo > >> > * Maintainer: d...@gentoo.org > >> > * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc > >> > userland_GNU > >> > * FEATURES: preserve-libs sandbox userpriv usersandbox > >> > * Determining the location of the kernel source code > >> > * Found kernel source directory: > >> > * /usr/src/linux > >> > * Found sources for kernel version: > >> > * 4.14.4-RT > >> > * Checking for suitable kernel configuration options... > >> > [ ok ] > >> Unpacking source... > >> Unpacking autofs-5.1.3.tar.xz to > >> /var/tmp/portage/net-fs/autofs-5.1.3/work > >> Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work > >> Preparing source in > >> /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... > >> > * Running eautoreconf in > >> > '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ... > >> > * This package has a configure.in file which has long been deprecated. > >> > Please > >> > * update it to use configure.ac instead as newer versions of autotools > >> > will die > >> > * when it finds this file. See https://bugs.gentoo.org/426262 for > >> > details. > >> > * Running autoconf --force ... > >> > [ ok ] > >> > * Running autoheader ... > >> > [ ok ] > >> > * Running elibtoolize in: autofs-5.1.3/ > >> Source prepared. > >> Configuring source in > >> /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... > >> Working in BUILD_DIR: > >> "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3" > >> > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure > >> > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu > >> > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > >> > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 > >> > --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d > >> > --with-mapdir=/etc/autofs --without-dmalloc --without-openldap > >> > --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking > >> > --disable-ext-env --enable-sloppy-mount --enable-force-shutdown > >> > --enable-ignore-busy --with-systemd=/usr/lib/systemd/system > >> > RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib > >> > configure: loading site script /usr/share/config.site > >> > checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin > >> > checking for Linux proc filesystem... yes > >> > checking location of the init.d directory... /etc/init.d > >> > checking for autofs configuration file directory... /etc/conf.d > >> > checking for autofs maps directory... /etc/autofs > >> > checking for autofs fifos directory... /run > >> > checking for autofs flag file directory... /run > >> > checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc > >> > checking whether the C compiler works... yes > >> > checking for C compiler default output file name... a.out > >> > checking for suffix of executables... > >> > checking whether we are cross compiling... no > >> > checking for suffix of object files... o > >> > checking whether we are using the GNU C compiler... yes > >> > checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes > >> > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none > >> > needed > >> > checking if libtirpc is requested and available... yes > >> > checking for getrpcbyname... yes > >> > checking for getservbyname... yes > >> > checking if malloc debugging is wanted... no > >> > checking for mount... /bin/mount > >> > checking for mount.nfs... /sbin/mount.nfs > >> > checking for umount... /bin/umount > >> > checking for fsck.ext2... /sbin/fsck.ext2 > >> > checking for fsck.ext3... /sbin/fsck.ext3 > >> > checking for fsck.ext4... /sbin/fsck.ext4 > >> > checking for modprobe... /sbin/modprobe > >> > checking for flex... /usr/bin/flex > >> > checking for bison... /usr/bin/bison > >> > checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib > >> > checking for rpcgen... no > >> > configure: error: required program RPCGEN
Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd
On Sat, Dec 9, 2017 at 11:54 AM, wrote: > On 12/09 06:27, Alexander Kapshuk wrote: >> On Sat, Dec 9, 2017 at 6:03 PM, wrote: >> > Hi, >> > >> > autofs-5.1.3 fails to compile: >> > solfire:/root>emerge -v autofs >> > >> > These are the packages that would be merged, in order: >> > >> > Calculating dependencies... done! >> > [ebuild R] net-fs/autofs-5.1.3::gentoo USE="libtirpc -dmalloc >> > -hesiod -ldap -mount-locking -sasl" 0 KiB >> > >> > Total: 1 package (1 reinstall), Size of downloads: 0 KiB >> > >> Verifying ebuild manifests >> Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo >> Failed to emerge net-fs/autofs-5.1.3, Log file: >> '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log' >> Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, >> 0.88 >> > * Package:net-fs/autofs-5.1.3 >> > * Repository: gentoo >> > * Maintainer: d...@gentoo.org >> > * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc >> > userland_GNU >> > * FEATURES: preserve-libs sandbox userpriv usersandbox >> > * Determining the location of the kernel source code >> > * Found kernel source directory: >> > * /usr/src/linux >> > * Found sources for kernel version: >> > * 4.14.4-RT >> > * Checking for suitable kernel configuration options... >> > [ ok ] >> Unpacking source... >> Unpacking autofs-5.1.3.tar.xz to >> /var/tmp/portage/net-fs/autofs-5.1.3/work >> Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work >> Preparing source in >> /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... >> > * Running eautoreconf in >> > '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ... >> > * This package has a configure.in file which has long been deprecated. >> > Please >> > * update it to use configure.ac instead as newer versions of autotools >> > will die >> > * when it finds this file. See https://bugs.gentoo.org/426262 for >> > details. >> > * Running autoconf --force ... >> > [ ok ] >> > * Running autoheader ... >> > [ ok ] >> > * Running elibtoolize in: autofs-5.1.3/ >> Source prepared. >> Configuring source in >> /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... >> Working in BUILD_DIR: >> "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3" >> > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure >> > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu >> > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share >> > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 >> > --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d >> > --with-mapdir=/etc/autofs --without-dmalloc --without-openldap >> > --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking >> > --disable-ext-env --enable-sloppy-mount --enable-force-shutdown >> > --enable-ignore-busy --with-systemd=/usr/lib/systemd/system >> > RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib >> > configure: loading site script /usr/share/config.site >> > checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin >> > checking for Linux proc filesystem... yes >> > checking location of the init.d directory... /etc/init.d >> > checking for autofs configuration file directory... /etc/conf.d >> > checking for autofs maps directory... /etc/autofs >> > checking for autofs fifos directory... /run >> > checking for autofs flag file directory... /run >> > checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc >> > checking whether the C compiler works... yes >> > checking for C compiler default output file name... a.out >> > checking for suffix of executables... >> > checking whether we are cross compiling... no >> > checking for suffix of object files... o >> > checking whether we are using the GNU C compiler... yes >> > checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes >> > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none >> > needed >> > checking if libtirpc is requested and available... yes >> > checking for getrpcbyname... yes >> > checking for getservbyname... yes >> > checking if malloc debugging is wanted... no >> > checking for mount... /bin/mount >> > checking for mount.nfs... /sbin/mount.nfs >> > checking for umount... /bin/umount >> > checking for fsck.ext2... /sbin/fsck.ext2 >> > checking for fsck.ext3... /sbin/fsck.ext3 >> > checking for fsck.ext4... /sbin/fsck.ext4 >> > checking for modprobe... /sbin/modprobe >> > checking for flex... /usr/bin/flex >> > checking for bison... /usr/bin/bison >> > checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib >> > checking for rpcgen... no >> > configure: error: required program RPCGEN not found >> > >> > >> > >> > configure misses rpcgen...and seems not to evaluate the USE of >> > libtirpc. >> > >> > I didn't find any fix/patch online. >> > >> > What goes wrong here? >> > >> > Cheers >> > Meino >> > >> > >> > >> If I'm re
Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd
On 12/09 06:27, Alexander Kapshuk wrote: > On Sat, Dec 9, 2017 at 6:03 PM, wrote: > > Hi, > > > > autofs-5.1.3 fails to compile: > > solfire:/root>emerge -v autofs > > > > These are the packages that would be merged, in order: > > > > Calculating dependencies... done! > > [ebuild R] net-fs/autofs-5.1.3::gentoo USE="libtirpc -dmalloc > > -hesiod -ldap -mount-locking -sasl" 0 KiB > > > > Total: 1 package (1 reinstall), Size of downloads: 0 KiB > > > Verifying ebuild manifests > Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo > Failed to emerge net-fs/autofs-5.1.3, Log file: > '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log' > Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, > 0.88 > > * Package:net-fs/autofs-5.1.3 > > * Repository: gentoo > > * Maintainer: d...@gentoo.org > > * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc > > userland_GNU > > * FEATURES: preserve-libs sandbox userpriv usersandbox > > * Determining the location of the kernel source code > > * Found kernel source directory: > > * /usr/src/linux > > * Found sources for kernel version: > > * 4.14.4-RT > > * Checking for suitable kernel configuration options... > > [ ok ] > Unpacking source... > Unpacking autofs-5.1.3.tar.xz to > /var/tmp/portage/net-fs/autofs-5.1.3/work > Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work > Preparing source in > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... > > * Running eautoreconf in > > '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ... > > * This package has a configure.in file which has long been deprecated. > > Please > > * update it to use configure.ac instead as newer versions of autotools > > will die > > * when it finds this file. See https://bugs.gentoo.org/426262 for details. > > * Running autoconf --force ... > > [ ok ] > > * Running autoheader ... > > [ ok ] > > * Running elibtoolize in: autofs-5.1.3/ > Source prepared. > Configuring source in > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... > Working in BUILD_DIR: > "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3" > > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure > > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu > > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 > > --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d > > --with-mapdir=/etc/autofs --without-dmalloc --without-openldap > > --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking > > --disable-ext-env --enable-sloppy-mount --enable-force-shutdown > > --enable-ignore-busy --with-systemd=/usr/lib/systemd/system > > RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib > > configure: loading site script /usr/share/config.site > > checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin > > checking for Linux proc filesystem... yes > > checking location of the init.d directory... /etc/init.d > > checking for autofs configuration file directory... /etc/conf.d > > checking for autofs maps directory... /etc/autofs > > checking for autofs fifos directory... /run > > checking for autofs flag file directory... /run > > checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc > > checking whether the C compiler works... yes > > checking for C compiler default output file name... a.out > > checking for suffix of executables... > > checking whether we are cross compiling... no > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes > > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed > > checking if libtirpc is requested and available... yes > > checking for getrpcbyname... yes > > checking for getservbyname... yes > > checking if malloc debugging is wanted... no > > checking for mount... /bin/mount > > checking for mount.nfs... /sbin/mount.nfs > > checking for umount... /bin/umount > > checking for fsck.ext2... /sbin/fsck.ext2 > > checking for fsck.ext3... /sbin/fsck.ext3 > > checking for fsck.ext4... /sbin/fsck.ext4 > > checking for modprobe... /sbin/modprobe > > checking for flex... /usr/bin/flex > > checking for bison... /usr/bin/bison > > checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib > > checking for rpcgen... no > > configure: error: required program RPCGEN not found > > > > > > > > configure misses rpcgen...and seems not to evaluate the USE of > > libtirpc. > > > > I didn't find any fix/patch online. > > > > What goes wrong here? > > > > Cheers > > Meino > > > > > > > If I'm reading the ebuild quoted below right, if 'libtirpc' is set, it > is net-libs/libtirpc that meets the dependency, otherwise it is glibc > compiled with rpc that does that. >
Re: [gentoo-user] autofs wants rpcgen despite libtirpc is USEd
On Sat, Dec 9, 2017 at 6:03 PM, wrote: > Hi, > > autofs-5.1.3 fails to compile: > solfire:/root>emerge -v autofs > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R] net-fs/autofs-5.1.3::gentoo USE="libtirpc -dmalloc -hesiod > -ldap -mount-locking -sasl" 0 KiB > > Total: 1 package (1 reinstall), Size of downloads: 0 KiB > Verifying ebuild manifests Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo Failed to emerge net-fs/autofs-5.1.3, Log file: '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log' Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, 0.88 > * Package:net-fs/autofs-5.1.3 > * Repository: gentoo > * Maintainer: d...@gentoo.org > * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc userland_GNU > * FEATURES: preserve-libs sandbox userpriv usersandbox > * Determining the location of the kernel source code > * Found kernel source directory: > * /usr/src/linux > * Found sources for kernel version: > * 4.14.4-RT > * Checking for suitable kernel configuration options... > [ ok ] Unpacking source... Unpacking autofs-5.1.3.tar.xz to /var/tmp/portage/net-fs/autofs-5.1.3/work Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work Preparing source in /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... > * Running eautoreconf in > '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ... > * This package has a configure.in file which has long been deprecated. > Please > * update it to use configure.ac instead as newer versions of autotools will > die > * when it finds this file. See https://bugs.gentoo.org/426262 for details. > * Running autoconf --force ... > [ ok ] > * Running autoheader ... > [ ok ] > * Running elibtoolize in: autofs-5.1.3/ Source prepared. Configuring source in /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... Working in BUILD_DIR: "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3" > /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure > --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 > --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d > --with-mapdir=/etc/autofs --without-dmalloc --without-openldap > --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking > --disable-ext-env --enable-sloppy-mount --enable-force-shutdown > --enable-ignore-busy --with-systemd=/usr/lib/systemd/system > RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib > configure: loading site script /usr/share/config.site > checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin > checking for Linux proc filesystem... yes > checking location of the init.d directory... /etc/init.d > checking for autofs configuration file directory... /etc/conf.d > checking for autofs maps directory... /etc/autofs > checking for autofs fifos directory... /run > checking for autofs flag file directory... /run > checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed > checking if libtirpc is requested and available... yes > checking for getrpcbyname... yes > checking for getservbyname... yes > checking if malloc debugging is wanted... no > checking for mount... /bin/mount > checking for mount.nfs... /sbin/mount.nfs > checking for umount... /bin/umount > checking for fsck.ext2... /sbin/fsck.ext2 > checking for fsck.ext3... /sbin/fsck.ext3 > checking for fsck.ext4... /sbin/fsck.ext4 > checking for modprobe... /sbin/modprobe > checking for flex... /usr/bin/flex > checking for bison... /usr/bin/bison > checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib > checking for rpcgen... no > configure: error: required program RPCGEN not found > > > > configure misses rpcgen...and seems not to evaluate the USE of > libtirpc. > > I didn't find any fix/patch online. > > What goes wrong here? > > Cheers > Meino > > > If I'm reading the ebuild quoted below right, if 'libtirpc' is set, it is net-libs/libtirpc that meets the dependency, otherwise it is glibc compiled with rpc that does that. /usr/portage/net-fs/autofs/autofs-5.1.3.ebuild:41,42 libtirpc? ( net-libs/libtirpc ) !libtirpc? ( elibc_glibc? ( sys-libs/glibc[rpc(-)] ) ) equery -q u sys-libs/glibc | grep rpc +rpc On my system, rpc is included in glibc: equery -q b /usr/bin/rpcgen sys-libs/glibc-2.25-r9 What's the cas
[gentoo-user] autofs wants rpcgen despite libtirpc is USEd
Hi, autofs-5.1.3 fails to compile: solfire:/root>emerge -v autofs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] net-fs/autofs-5.1.3::gentoo USE="libtirpc -dmalloc -hesiod -ldap -mount-locking -sasl" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-fs/autofs-5.1.3::gentoo >>> Failed to emerge net-fs/autofs-5.1.3, Log file: >>> '/var/tmp/portage/net-fs/autofs-5.1.3/temp/build.log' >>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.71, 0.95, 0.88 * Package:net-fs/autofs-5.1.3 * Repository: gentoo * Maintainer: d...@gentoo.org * USE:abi_x86_64 amd64 elibc_glibc kernel_linux libtirpc userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 4.14.4-RT * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking autofs-5.1.3.tar.xz to /var/tmp/portage/net-fs/autofs-5.1.3/work >>> Source unpacked in /var/tmp/portage/net-fs/autofs-5.1.3/work >>> Preparing source in /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 >>> ... * Running eautoreconf in '/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3' ... * This package has a configure.in file which has long been deprecated. Please * update it to use configure.ac instead as newer versions of autotools will die * when it finds this file. See https://bugs.gentoo.org/426262 for details. * Running autoconf --force ... [ ok ] * Running autoheader ... [ ok ] * Running elibtoolize in: autofs-5.1.3/ >>> Source prepared. >>> Configuring source in >>> /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3 ... >>> Working in BUILD_DIR: >>> "/var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3" /var/tmp/portage/net-fs/autofs-5.1.3/work/autofs-5.1.3/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --docdir=/usr/share/doc/autofs-5.1.3 --with-confdir=/etc/conf.d --with-mapdir=/etc/autofs --without-dmalloc --without-openldap --with-libtirpc --without-sasl --without-hesiod --disable-mount-locking --disable-ext-env --enable-sloppy-mount --enable-force-shutdown --enable-ignore-busy --with-systemd=/usr/lib/systemd/system RANLIB=/usr/bin/x86_64-pc-linux-gnu-ranlib configure: loading site script /usr/share/config.site checking for binaries in... /usr/bin:/bin:/usr/sbin:/sbin checking for Linux proc filesystem... yes checking location of the init.d directory... /etc/init.d checking for autofs configuration file directory... /etc/conf.d checking for autofs maps directory... /etc/autofs checking for autofs fifos directory... /run checking for autofs flag file directory... /run checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking if libtirpc is requested and available... yes checking for getrpcbyname... yes checking for getservbyname... yes checking if malloc debugging is wanted... no checking for mount... /bin/mount checking for mount.nfs... /sbin/mount.nfs checking for umount... /bin/umount checking for fsck.ext2... /sbin/fsck.ext2 checking for fsck.ext3... /sbin/fsck.ext3 checking for fsck.ext4... /sbin/fsck.ext4 checking for modprobe... /sbin/modprobe checking for flex... /usr/bin/flex checking for bison... /usr/bin/bison checking for ranlib... /usr/bin/x86_64-pc-linux-gnu-ranlib checking for rpcgen... no configure: error: required program RPCGEN not found configure misses rpcgen...and seems not to evaluate the USE of libtirpc. I didn't find any fix/patch online. What goes wrong here? Cheers Meino
[gentoo-user] autofs config
I've never used autofs and am trying to get it setup.
Following the debian wiki and an Ubuntu howto.
I've installed the pkg:
aptitude search ^autofs|grep ^i
i autofs - kernel-based automounter for Linux
created mount point: mkdir /projects-nfs
I've edited /etc/auto.master by adding this line:
/projects-nfs /etc/auto.master.d/prj-nfs.autofs --timeout=180
Created the directory `mkdir /etc/auto.master.d' and spec'ed in
`/etc/auto.master'.
created /etc/auto.master.d/prj-nfs.autofs like so (as spec'ed in auto.master):
d0 --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/d0
dv --fstype=nfs4,rw,soft,intr191.168.1.42:/projects/dv
Those directories on that host are available.
They reside a solaris (x86) host and set to be available by nfs.
They can be mounted manually{to different dir than above}:
mount -t nfs 2x:/projects/dv /nfs/dv
Checking /nfs/dv... I find it is mounted.
Re: [gentoo-user] autofs
Apparently, though unproven, at 23:11 on Saturday 04 June 2011, Stroller did opine thusly: > On 4 June 2011, at 16:10, Stéphane Guedon wrote: > > ... > > In home network, you share many types of files ! The first I think is DVD > > iso, which is huge (too large to go through coda) and not streamable... > > (but I admit it's not the best exemple !) > > I'm not sure what coda is, but I "stream" DVD .iso files over Samba to my > set-top-box. [1] [2] coda and andrewfs are the same class of thing - a network connected file system. Both claim to deal nicely with becoming disconnected, then will just wait for the other end to come back online. But without the large exposure that NFS and samba already have, support is somewhat spotty still. > DVD .iso files are no longer considered "huge". There are now people who > rip blu-rays to store them on the NAS - those are each c 50gb. I have visions of Aunt Tillie trying to do that off a VFAT usb disk using Windows. :-0 -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] autofs
On 4 June 2011, at 16:10, Stéphane Guedon wrote: > ... > In home network, you share many types of files ! The first I think is DVD > iso, > which is huge (too large to go through coda) and not streamable... (but I > admit it's not the best exemple !) I'm not sure what coda is, but I "stream" DVD .iso files over Samba to my set-top-box. [1] [2] DVD .iso files are no longer considered "huge". There are now people who rip blu-rays to store them on the NAS - those are each c 50gb. Stroller. [1] http://www.expertreviews.co.uk/media-streamers/1281361/ac-ryan-playon-hd-mini [2] http://www.trustedreviews.com/A-C--Ryan-Playon-HD-Mini_Peripheral_review
Re: [gentoo-user] autofs
On Saturday 04 June 2011 02:40:12 William Kenworthy wrote: > On Fri, 2011-06-03 at 14:57 +0200, Florian Philipp wrote: > > Am 03.06.2011 14:25, schrieb Alan McKinnon: > > > Apparently, though unproven, at 14:18 on Friday 03 June 2011, Volker > > > Armin > > > > > > Hemmann did opine thusly: > > >> On Friday 03 June 2011 13:37:54 Stéphane Guedon wrote: > > >>> On Friday 03 June 2011 12:55:58 Alan McKinnon wrote: > > Apparently, though unproven, at 12:44 on Friday 03 June 2011, > > Stéphane Guedon > > > > did opine thusly: > > [...] > > > > The point is that NFS was not designed with laptops and other > > devices that can be disconnected in mind. It was designed for > > secure LANs that do not change much, and laptops present issues > > that are not easy to solve. > > > > [...] > > > > >>> Nfs hasn't been designed for laptop, it's ok. But, appart from coda > > >>> (which has a file size limit of 1 giga, so, useless in home > > >>> networking), I know nothing that is fit for network file-sharing for > > >>> laptop (the laptop isn't the server of course). > > >>> > > >>> I search a solution for that since years ! > > >> > > >> samba? > > > > > > +1 > > > > > > Samba works nicely for ad-hoc connections, the kind of thing Windows > > > clients would do. And it's a lot more tolerant of connections going > > > away than NFS. > > > > I always was under the impression that NFS is more fault-tolerant on the > > network because of its usage of stateless UDP connections whereas CIFS > > usually freezes when the connection is lost. In the end, both issue an > > IO error, usually crashing an unprepared application. So, in which > > regard performs CIFS better with interrupted connections? > > > > That being said, I always use NFS over TCP because of performance issues > > with UDP and wireless LAN. > > > > Regards, > > Florian Philipp > > No, its ok in a fixed network but you get wierd issues like clients > hanging on shutdown because the NFS server goes away first, and its an > administrative pita when it stops working - could be firewall, something > missed in a new kernel etc. > > Ive been using it for mythtv and diskless systems (NFS over TCP) for > quite awhile and its a fight every few months to find out why host x > syuddenly doesnt want to play. But otherwise works well use wise in a > controlled environment. > > Laptops are a whole different matter though - you might be better off > side stepping if its only looking at media by looking into streaming > rather than storage mapping. Otherwise, Samba is probably the next > best. > > BillK In home network, you share many types of files ! The first I think is DVD iso, which is huge (too large to go through coda) and not streamable... (but I admit it's not the best exemple !) You share also documents (tax papers scans, ilness and doctors certificates...). And I share first of all Portage tree and distfiles ! Medias can be streamed, but not that ! -- Stéphane Guedon page web : http://www.22decembre.eu/ carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] autofs
On Fri, 2011-06-03 at 14:57 +0200, Florian Philipp wrote: > Am 03.06.2011 14:25, schrieb Alan McKinnon: > > Apparently, though unproven, at 14:18 on Friday 03 June 2011, Volker Armin > > Hemmann did opine thusly: > > > >> On Friday 03 June 2011 13:37:54 Stéphane Guedon wrote: > >>> On Friday 03 June 2011 12:55:58 Alan McKinnon wrote: > Apparently, though unproven, at 12:44 on Friday 03 June 2011, Stéphane > Guedon > > did opine thusly: > [...] > > The point is that NFS was not designed with laptops and other devices > that can be disconnected in mind. It was designed for secure LANs that > do not change much, and laptops present issues that are not easy to > solve. > [...] > >>> > >>> Nfs hasn't been designed for laptop, it's ok. But, appart from coda > >>> (which has a file size limit of 1 giga, so, useless in home networking), > >>> I know nothing that is fit for network file-sharing for laptop (the > >>> laptop isn't the server of course). > >>> > >>> I search a solution for that since years ! > >> > >> samba? > > > > +1 > > > > Samba works nicely for ad-hoc connections, the kind of thing Windows > > clients > > would do. And it's a lot more tolerant of connections going away than NFS. > > > > > > I always was under the impression that NFS is more fault-tolerant on the > network because of its usage of stateless UDP connections whereas CIFS > usually freezes when the connection is lost. In the end, both issue an > IO error, usually crashing an unprepared application. So, in which > regard performs CIFS better with interrupted connections? > > That being said, I always use NFS over TCP because of performance issues > with UDP and wireless LAN. > > Regards, > Florian Philipp > No, its ok in a fixed network but you get wierd issues like clients hanging on shutdown because the NFS server goes away first, and its an administrative pita when it stops working - could be firewall, something missed in a new kernel etc. Ive been using it for mythtv and diskless systems (NFS over TCP) for quite awhile and its a fight every few months to find out why host x syuddenly doesnt want to play. But otherwise works well use wise in a controlled environment. Laptops are a whole different matter though - you might be better off side stepping if its only looking at media by looking into streaming rather than storage mapping. Otherwise, Samba is probably the next best. BillK -- William Kenworthy Home in Perth!
Re: [gentoo-user] autofs
Apparently, though unproven, at 14:57 on Friday 03 June 2011, Florian Philipp did opine thusly: > Am 03.06.2011 14:25, schrieb Alan McKinnon: > > Apparently, though unproven, at 14:18 on Friday 03 June 2011, Volker > > Armin > > > > Hemmann did opine thusly: > >> On Friday 03 June 2011 13:37:54 Stéphane Guedon wrote: > >>> On Friday 03 June 2011 12:55:58 Alan McKinnon wrote: > Apparently, though unproven, at 12:44 on Friday 03 June 2011, Stéphane > Guedon > > did opine thusly: > [...] > > The point is that NFS was not designed with laptops and other devices > that can be disconnected in mind. It was designed for secure LANs that > do not change much, and laptops present issues that are not easy to > solve. > > [...] > > >>> Nfs hasn't been designed for laptop, it's ok. But, appart from coda > >>> (which has a file size limit of 1 giga, so, useless in home > >>> networking), I know nothing that is fit for network file-sharing for > >>> laptop (the laptop isn't the server of course). > >>> > >>> I search a solution for that since years ! > >> > >> samba? > > > > +1 > > > > Samba works nicely for ad-hoc connections, the kind of thing Windows > > clients would do. And it's a lot more tolerant of connections going away > > than NFS. > > I always was under the impression that NFS is more fault-tolerant on the > network because of its usage of stateless UDP connections whereas CIFS > usually freezes when the connection is lost. In the end, both issue an > IO error, usually crashing an unprepared application. So, in which > regard performs CIFS better with interrupted connections? I find that when an NFS server disappears from the client's view, the only thing that brings it back is making the server visible again. True, there are options that modify this behaviour (hard, soft) but they come with their own risks as described in the man page. Trying to unmount an NFS mount with no server is painful, and all too easy to do if you carry your laptop to a meeting room in another building. CIFS can usually at least be killed (depending on how it's mounted) - a kioslave in konqueror for example is easy to kill. Neither option is well suited for laptops IMO but on balance CIFS tends to be easier for the user to deal with. > That being said, I always use NFS over TCP because of performance issues > with UDP and wireless LAN. Smart move. I genuinely feel that the use-case for NFS over UDP has largely gone away in these modern times and TCP is the better choice for normal use. OT, but the same applies to auth systems i.e. tacacs vs radius -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] autofs
Am 03.06.2011 14:25, schrieb Alan McKinnon: > Apparently, though unproven, at 14:18 on Friday 03 June 2011, Volker Armin > Hemmann did opine thusly: > >> On Friday 03 June 2011 13:37:54 Stéphane Guedon wrote: >>> On Friday 03 June 2011 12:55:58 Alan McKinnon wrote: Apparently, though unproven, at 12:44 on Friday 03 June 2011, Stéphane Guedon did opine thusly: [...] The point is that NFS was not designed with laptops and other devices that can be disconnected in mind. It was designed for secure LANs that do not change much, and laptops present issues that are not easy to solve. [...] >>> >>> Nfs hasn't been designed for laptop, it's ok. But, appart from coda >>> (which has a file size limit of 1 giga, so, useless in home networking), >>> I know nothing that is fit for network file-sharing for laptop (the >>> laptop isn't the server of course). >>> >>> I search a solution for that since years ! >> >> samba? > > +1 > > Samba works nicely for ad-hoc connections, the kind of thing Windows clients > would do. And it's a lot more tolerant of connections going away than NFS. > > I always was under the impression that NFS is more fault-tolerant on the network because of its usage of stateless UDP connections whereas CIFS usually freezes when the connection is lost. In the end, both issue an IO error, usually crashing an unprepared application. So, in which regard performs CIFS better with interrupted connections? That being said, I always use NFS over TCP because of performance issues with UDP and wireless LAN. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] autofs
Apparently, though unproven, at 14:18 on Friday 03 June 2011, Volker Armin Hemmann did opine thusly: > On Friday 03 June 2011 13:37:54 Stéphane Guedon wrote: > > On Friday 03 June 2011 12:55:58 Alan McKinnon wrote: > > > Apparently, though unproven, at 12:44 on Friday 03 June 2011, Stéphane > > > Guedon > > > > > > did opine thusly: > > > > anyone use autofs to manage mounting of nfs on a laptop ? > > > > > > Is this mounting a share from an nfs server onto a laptop? > > > > > > > Is it fluent, > > > > easy to use ? > > > > > > It's NFS. The words "nfs" and "fluent, easy to use" do not belong in > > > the same sentence unless there's a "not" in the middle. > > > > > > The point is that NFS was not designed with laptops and other devices > > > that can be disconnected in mind. It was designed for secure LANs that > > > do not change much, and laptops present issues that are not easy to > > > solve. > > > > > > > How many shares maximum ? > > > > > > From a server? Hundreds, with ease. NFS is not the bottleneck, your > > > shares are limited by how much bandwidth you have over the network. > > > > Ok, it's a beginning.. :-) thank you ! > > > > Nfs hasn't been designed for laptop, it's ok. But, appart from coda > > (which has a file size limit of 1 giga, so, useless in home networking), > > I know nothing that is fit for network file-sharing for laptop (the > > laptop isn't the server of course). > > > > I search a solution for that since years ! > > samba? +1 Samba works nicely for ad-hoc connections, the kind of thing Windows clients would do. And it's a lot more tolerant of connections going away than NFS. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] autofs
On Friday 03 June 2011 13:37:54 Stéphane Guedon wrote: > On Friday 03 June 2011 12:55:58 Alan McKinnon wrote: > > Apparently, though unproven, at 12:44 on Friday 03 June 2011, Stéphane > > Guedon > > > > did opine thusly: > > > anyone use autofs to manage mounting of nfs on a laptop ? > > > > Is this mounting a share from an nfs server onto a laptop? > > > > > Is it fluent, > > > easy to use ? > > > > It's NFS. The words "nfs" and "fluent, easy to use" do not belong in the > > same sentence unless there's a "not" in the middle. > > > > The point is that NFS was not designed with laptops and other devices > > that can be disconnected in mind. It was designed for secure LANs that > > do not change much, and laptops present issues that are not easy to > > solve. > > > > > How many shares maximum ? > > > > From a server? Hundreds, with ease. NFS is not the bottleneck, your > > shares are limited by how much bandwidth you have over the network. > > Ok, it's a beginning.. :-) thank you ! > > Nfs hasn't been designed for laptop, it's ok. But, appart from coda (which > has a file size limit of 1 giga, so, useless in home networking), I know > nothing that is fit for network file-sharing for laptop (the laptop isn't > the server of course). > > I search a solution for that since years ! samba?
Re: [gentoo-user] autofs
On 2011-06-03 12:44, Stéphane Guedon wrote: > anyone use autofs to manage mounting of nfs on a laptop ? Is it fluent, easy > to I'm not using any auto-mounters currently but this link may help(?): http://www.linux-tutorial.info/modules.php?name=MContent&pageid=153 HTH Best regards Peter K
Re: [gentoo-user] autofs
On Friday 03 June 2011 12:55:58 Alan McKinnon wrote: > Apparently, though unproven, at 12:44 on Friday 03 June 2011, Stéphane > Guedon > > did opine thusly: > > anyone use autofs to manage mounting of nfs on a laptop ? > > Is this mounting a share from an nfs server onto a laptop? > > > Is it fluent, > > easy to use ? > > It's NFS. The words "nfs" and "fluent, easy to use" do not belong in the > same sentence unless there's a "not" in the middle. > > The point is that NFS was not designed with laptops and other devices that > can be disconnected in mind. It was designed for secure LANs that do not > change much, and laptops present issues that are not easy to solve. > > > How many shares maximum ? > > From a server? Hundreds, with ease. NFS is not the bottleneck, your shares > are limited by how much bandwidth you have over the network. Ok, it's a beginning.. :-) thank you ! Nfs hasn't been designed for laptop, it's ok. But, appart from coda (which has a file size limit of 1 giga, so, useless in home networking), I know nothing that is fit for network file-sharing for laptop (the laptop isn't the server of course). I search a solution for that since years ! -- Stéphane Guedon page web : http://www.22decembre.eu/ carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] autofs
Apparently, though unproven, at 12:44 on Friday 03 June 2011, Stéphane Guedon did opine thusly: > anyone use autofs to manage mounting of nfs on a laptop ? Is this mounting a share from an nfs server onto a laptop? > Is it fluent, > easy to use ? It's NFS. The words "nfs" and "fluent, easy to use" do not belong in the same sentence unless there's a "not" in the middle. The point is that NFS was not designed with laptops and other devices that can be disconnected in mind. It was designed for secure LANs that do not change much, and laptops present issues that are not easy to solve. > How many shares maximum ? From a server? Hundreds, with ease. NFS is not the bottleneck, your shares are limited by how much bandwidth you have over the network. -- alan dot mckinnon at gmail dot com
[gentoo-user] autofs
anyone use autofs to manage mounting of nfs on a laptop ? Is it fluent, easy to use ? How many shares maximum ? thanks -- Stéphane Guedon page web : http://www.22decembre.eu/ carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] AutoFS with LDAP ***SOLVED***
On Mon, Oct 20, 2008 at 01:31:00PM +0100, Mike wrote: > > Thanks Fred, > > I think I found the answer here: "[bug on amd64 try this: $ > CFLAGS="-DLDAP_DEPRECATED" emerge autofs]". It's a 64bit system, so I > will try remerging it with LDAP_DEPRECATED and see what happenes. > > Mike. Thanks again Fred. I'd tried in the past with the ldap USE flag. This time I tried "CFLAGS="-DLDAP_DEPRECATED" emerge autofs" and it compiled and worked! Thanks again, Mike.
Re: [gentoo-user] AutoFS with LDAP
On Mon, Oct 20, 2008 at 11:08:42AM +0200, Fred Elno wrote: > Yes I also use autofs with openldap. > My setup is as this: the PDC is running on a gentoo box and provide system > authentification with openldap to windows > client and also gentoo client, I also use samba for filesharing between > client and server. > Because I don't want my users being able to see at other users home directory > I use autofs which mount only user > logged in home directory on the client. > > I am not a specialist in Openldap so I don't know if I will be able to help > you, but if it can help, I can give you > this link : http://www.drakonix.fr/index.php?id=gentoo&tab=21&pid=26#t03 > > It point to my setup documentation and perhaps you will found usefull > information. > You will also find some links to other wiki's and doc which talk about this > subject. > > Oh I forgot it is written in French but all the command used and file > configuration are written > And excuse me for my poor English ;) > > Hope it's help > > Fred Thanks Fred, I think I found the answer here: "[bug on amd64 try this: $ CFLAGS="-DLDAP_DEPRECATED" emerge autofs]". It's a 64bit system, so I will try remerging it with LDAP_DEPRECATED and see what happenes. Mike.
Re: [gentoo-user] AutoFS with LDAP
Yes I also use autofs with openldap. My setup is as this: the PDC is running on a gentoo box and provide system authentification with openldap to windows client and also gentoo client, I also use samba for filesharing between client and server. Because I don't want my users being able to see at other users home directory I use autofs which mount only user logged in home directory on the client. I am not a specialist in Openldap so I don't know if I will be able to help you, but if it can help, I can give you this link : http://www.drakonix.fr/index.php?id=gentoo&tab=21&pid=26#t03 It point to my setup documentation and perhaps you will found usefull information. You will also find some links to other wiki's and doc which talk about this subject. Oh I forgot it is written in French but all the command used and file configuration are written And excuse me for my poor English ;) Hope it's help Fred > Folks, > > Has anyone used AutoFS with the automounter information coming from > LDAP? > > I have a LDAP server with the necessary maps setup. I have a number of > LDAP clients on Debian successfully using this. However, I cannot get > this to work with Gentoo. When I try to start autofs I get a message > saying "failed". I have also tried starting by handing using the > automount command that is running on my Debian box, however, it just > exits. The /usr/lib/autofs/autofs-ldap-auto-master returns the correct > information. However, automounter will not start. > > Mike. > > http://www.drakonix.fr
[gentoo-user] AutoFS with LDAP
Folks, Has anyone used AutoFS with the automounter information coming from LDAP? I have a LDAP server with the necessary maps setup. I have a number of LDAP clients on Debian successfully using this. However, I cannot get this to work with Gentoo. When I try to start autofs I get a message saying "failed". I have also tried starting by handing using the automount command that is running on my Debian box, however, it just exits. The /usr/lib/autofs/autofs-ldap-auto-master returns the correct information. However, automounter will not start. Mike.
Re: [gentoo-user] Autofs or ivman?
On Thursday 17 January 2008 10:08:22 pm Stroller wrote: > Sorry for taking so long to reply to this - I've been kinda busy with > work the last few days. > > On 6 Jan 2008, at 17:25, Alan McKinnon wrote: > > On Sunday 06 January 2008, Stroller wrote: > >> Hi there, > >> > >> I was on #gentoo yesterday asking about autofs & someone recommended > >> ivman instead. > >> Which does gentoo-users think I should use? > > > > Dilemmas like this are best resolved by finding out what problem a > > technology was designed to solve. > > > > A good example of the kind of problem autofs solves is exporting home > > directories on a large server that has many accounts... > > > > ... With autofs you essentially tell the server > > that this is user joe, it exports his home dir on the fly, creates a > > directory /home/joe on his workstation (/home must already exist)and > > mounts the NFS export there. > > > > Now, you don't appear to be doing something like that :-) > > Many thanks for your reply - it was quite insightful. In fact, autofs > would be quite useful for my /mnt/video/[a...z] volumes. > > It makes me still wonder, however, why so many people seem to use > autofs for /mnt/floppy, /mnt/cdrom &c, tho'! > > > ... the impetus for other solutions > > to be developed, like ivman. > > My concern over ivman - which looks ideal for much of what I want to > do - is that it's not clear if it's maintained. For network mounting / > usr/portage I guess I can just use NFS and just stick the mount in > the clients' /etc/fstab, but ivman looks great for automounting > portable media. As I said in my original posting [1], the state of > ivman looks to be in a bit of a mess and I'm kinda reluctant to mess > about with it if it's going to be obsolete in a year or two - someone > please persuade me this isn't going to happen!! ;) > > Stroller. > > > [1] http://article.gmane.org/gmane.linux.gentoo.user/192551 I use autofs for just about everything imagineable... What's the problem with using it for removable media? -- From the Desk of: Jerome D. McBride -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Autofs or ivman?
Sorry for taking so long to reply to this - I've been kinda busy with work the last few days. On 6 Jan 2008, at 17:25, Alan McKinnon wrote: On Sunday 06 January 2008, Stroller wrote: Hi there, I was on #gentoo yesterday asking about autofs & someone recommended ivman instead. Which does gentoo-users think I should use? Dilemmas like this are best resolved by finding out what problem a technology was designed to solve. A good example of the kind of problem autofs solves is exporting home directories on a large server that has many accounts... ... With autofs you essentially tell the server that this is user joe, it exports his home dir on the fly, creates a directory /home/joe on his workstation (/home must already exist)and mounts the NFS export there. Now, you don't appear to be doing something like that :-) Many thanks for your reply - it was quite insightful. In fact, autofs would be quite useful for my /mnt/video/[a...z] volumes. It makes me still wonder, however, why so many people seem to use autofs for /mnt/floppy, /mnt/cdrom &c, tho'! ... the impetus for other solutions to be developed, like ivman. My concern over ivman - which looks ideal for much of what I want to do - is that it's not clear if it's maintained. For network mounting / usr/portage I guess I can just use NFS and just stick the mount in the clients' /etc/fstab, but ivman looks great for automounting portable media. As I said in my original posting [1], the state of ivman looks to be in a bit of a mess and I'm kinda reluctant to mess about with it if it's going to be obsolete in a year or two - someone please persuade me this isn't going to happen!! ;) Stroller. [1] http://article.gmane.org/gmane.linux.gentoo.user/192551 -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Autofs or ivman?
On Sunday 06 January 2008, Stroller wrote: > Hi there, > > I was on #gentoo yesterday asking about autofs & someone recommended > ivman instead. > Which does gentoo-users think I should use? Dilemmas like this are best resolved by finding out what problem a technology was designed to solve. A good example of the kind of problem autofs solves is exporting home directories on a large server that has many accounts, used in conjunction with NFS and NIS, and anyone can log in from any workstation at any time. This scenario is common - think thin clients Say you have 100 accounts and user joe logs onto the network. You *could* export /home to his workstation, but that exposes everyone else's homedir as well. With autofs you essentially tell the server that this is user joe, it exports his home dir on the fly, creates a directory /home/joe on his workstation (/home must already exist)and mounts the NFS export there. Now, you don't appear to be doing something like that :-) You can do many wonderful things with autofs, but it often involves complex hacks and workarounds, which is the impetus for other solutions to be developed, like ivman. -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] Autofs or ivman?
Hi there, I was on #gentoo yesterday asking about autofs & someone recommended ivman instead. Which does gentoo-users think I should use? My principal interest is in NFS mounting /usr/portage on my PS3 & an old laptop, as neither has a lot of disk-space - I have an always-on server that can export the directory - but also in mounting a bunch of /media/video/[0..9]/ directories. I guess I'm likely to use CD / DVD in the near future & USB / CF flash memory at some point in the future - I can imagine it being desirable to have the system mount one device as /mnt/external- harddrive and another at /media/photos (determined by device / vendor ID?) but I'm not sure if this is the job of the automounter or udev? Reading the autofs howto [1], it bothers me that common practice is to have a bunch of /mnt/auto/foo, /mnt/auto/bar, directories symlinked into the places they're REALLY supposed to go. Another guide makes a /var/autofs/ tree of directories, but whatever - why do I have to have this extra clutter of all these extra symlinks?!?! I just want the network filesystem to be mounted in some sensible place, just as if I'd typed `mount server:/usr/portage /usr/portage`. I appreciate there's probably a good reason for the way autofs works, bit it does make ivman look more interesting. My concern with ivman is that googling it doesn't turn up a bunch of beginners' guides the way googling autofs does. The ivman howto [3] discusses incompatibility problems with different versions, and indicates that the /etc/init.d/script isn't provided by the ebuild, but must be managed outside of portage. I don't have a problem with that, per-se, but it suggests to me that ivman isn't so well supported, a suggestion which seems to be supported by ivman's sourceforge page [4] which was last updated February last year and which says "Ivman is currently developed by ?" So it's a bit of a dilemma for me. Because of my compulsive nature, autofs' clutter of symlinks really bothers me, and ivman's ConfigActions look really powerful - it looks like you can have it automatically exec a command when a specific device is plugged in, for instance. But I want to set this up once & forget it - I really don't want to be learning & configuring now a package which will be unsupported in the future. Thanks in advance for any comments, Stroller. [1] http://gentoo-wiki.com/HOWTO_Auto_mount_filesystems_(AUTOFS) [2] http://www.greenfly.org/tips/autofs.html [3] http://gentoo-wiki.com/HOWTO_ivman [4] http://ivman.sourceforge.net/ -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] autofs, supermount, submount... which is best for Gentoo?
On Wed, 13 Oct 2004, Jochen Schalanda wrote: From: Jochen Schalanda <[EMAIL PROTECTED]> Subject: Re: [gentoo-user] autofs, supermount, submount... which is best for Gentoo? Newsgroups: linux.gentoo.user On 10/13/2004 11:10 PM, Felix Tiede wrote: submount is supposed to supersede supermount as supermount is running in kernel-space, while submount is a user-space-tool. I think that is not quite correct. submount is a kernel module, hence it runs in kernel space. A userspace solution for automounting would be dbus+hal+ivman or gnome-volume-manager. I tried supermount, submount, and dbus+hal+ivman and at the moment I like submount best since it perfectly fits my needs. But as already said, all the programs (automount, supermount, submount, ivman) have a slightly different featureset, so one should really try them all and decide afterwards which one to choose. Jochen Very informative, thanks. I think I'll go with submount. -Thufir -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] autofs, supermount, submount... which is best for Gentoo?
[EMAIL PROTECTED] schreef: >> >> Very informative, thanks. I think I'll go with submount. > These are the packages that I would merge, in order: > > Calculating dependencies ...done! [ebuild N] > sys-fs/submount-0.9-r2 159 kB > > Total size of downloads: 159 kB localhost ~ # emerge submount > Calculating dependencies ...done! emerge (1 of 1) sys-fs/submount-0.9-r2 to / > 15:04:38 (64.11 KB/s) - > `/usr/portage/distfiles/submount-0.9.tar.gz' saved [75476/75476] > md5 files ;-) submount-0.9-r2.ebuild md5 files ;-) files/digest-submount-0.9-r2 md5 src_uri ;-) submount-2.4-0.9.tar.gz md5 src_uri ;-) submount-0.9.tar.gz > * Determining the location of the kernel source code * Found kernel > source directory: * /usr/src/linux * Could not find a usable > .config in the kernel source directory. * Please ensure that > /usr/src/linux points to a configured set of Linux sources. * If you > are using KBUILD_OUTPUT, please set the environment var so that * it > points to the necessary object directory so that it might find > .config. > > !!! ERROR: sys-fs/submount-0.9-r2 failed. !!! Function > linux-info_pkg_setup, Line 537, Exitcode 1 !!! Unable to calculate > Linux Kernel version !!! If you need support, post the topmost build > error, NOT this status message. > > > I'm not sure what's meant by the topmost build error, but as it's not > too large, I included everything. > What is meant is the last output right before "ERROR:"; in this case, it is * Could not find a usable .config in the kernel source directory. * Please ensure that /usr/src/linux points to a configured set of Linux sources. This package compiles against the kernel, as you can see from * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux However, the kernel source that the /usr/src/linux symlink points to has not been configured using make (menu/x)config. Therefore there is no .config file that the package can examine to ensure that the kernel source in question has/will be built with the support that the package requires. You don't have to build or install this kernel source, but you do have to configure it (properly for the submount package) before you attempt to install the submount package. I'd think that the wiki entry will detail the necessary kernel settings. Hope this helps. Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] autofs, supermount, submount... which is best for Gentoo?
On Thu, 23 Mar 2006 15:06:59 + (GMT), [EMAIL PROTECTED] wrote: > * Determining the location of the kernel source code > * Found kernel source directory: > * /usr/src/linux > * Could not find a usable .config in the kernel source directory. > * Please ensure that /usr/src/linux points to a configured set of > Linux sources. As it says, make sure /usr/src/linux is a link to a kernel source you have configured, usually the running kernel. It looks like it currently points to newly-installed sources that you have not yet run make menuconfig/xconfig on. -- Neil Bothwick WinErr 012: Window closed - Do not look inside signature.asc Description: PGP signature
Re: [gentoo-user] autofs, supermount, submount... which is best for Gentoo?
On Thu, 23 Mar 2006, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Subject: Re: [gentoo-user] autofs, supermount, submount... which is best for Gentoo? On Wed, 13 Oct 2004, Jochen Schalanda wrote: From: Jochen Schalanda <[EMAIL PROTECTED]> Subject: Re: [gentoo-user] autofs, supermount, submount... which is best for Gentoo? Newsgroups: linux.gentoo.user On 10/13/2004 11:10 PM, Felix Tiede wrote: > submount is supposed to supersede supermount as supermount is running in > kernel-space, while submount is a user-space-tool. I think that is not quite correct. submount is a kernel module, hence it runs in kernel space. A userspace solution for automounting would be dbus+hal+ivman or gnome-volume-manager. I tried supermount, submount, and dbus+hal+ivman and at the moment I like submount best since it perfectly fits my needs. But as already said, all the programs (automount, supermount, submount, ivman) have a slightly different featureset, so one should really try them all and decide afterwards which one to choose. Jochen Very informative, thanks. I think I'll go with submount. -Thufir localhost ~ # localhost ~ # localhost ~ # emerge -vp submount These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N] sys-fs/submount-0.9-r2 159 kB Total size of downloads: 159 kB localhost ~ # emerge submount Calculating dependencies ...done! emerge (1 of 1) sys-fs/submount-0.9-r2 to / Downloading http://distfiles.gentoo.org/distfiles/submount-2.4-0.9.tar.gz --15:04:32-- http://distfiles.gentoo.org/distfiles/submount-2.4-0.9.tar.gz => `/usr/portage/distfiles/submount-2.4-0.9.tar.gz' Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ... Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 88,203 (86K) [application/x-gzip] 100%[>] 88,20326.49K/sETA 00:00 15:04:36 (26.47 KB/s) - `/usr/portage/distfiles/submount-2.4-0.9.tar.gz' saved [88203/88203] Downloading http://distfiles.gentoo.org/distfiles/submount-0.9.tar.gz --15:04:36-- http://distfiles.gentoo.org/distfiles/submount-0.9.tar.gz => `/usr/portage/distfiles/submount-0.9.tar.gz' Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ... Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 75,476 (74K) [application/x-gzip] 100%[>] 75,47664.24K/s 15:04:38 (64.11 KB/s) - `/usr/portage/distfiles/submount-0.9.tar.gz' saved [75476/75476] md5 files ;-) submount-0.9-r2.ebuild md5 files ;-) files/digest-submount-0.9-r2 md5 src_uri ;-) submount-2.4-0.9.tar.gz md5 src_uri ;-) submount-0.9.tar.gz * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Could not find a usable .config in the kernel source directory. * Please ensure that /usr/src/linux points to a configured set of Linux sources. * If you are using KBUILD_OUTPUT, please set the environment var so that * it points to the necessary object directory so that it might find .config. !!! ERROR: sys-fs/submount-0.9-r2 failed. !!! Function linux-info_pkg_setup, Line 537, Exitcode 1 !!! Unable to calculate Linux Kernel version !!! If you need support, post the topmost build error, NOT this status message. localhost ~ # localhost ~ # date Thu Mar 23 15:05:01 GMT 2006 localhost ~ # I'm not sure what's meant by the topmost build error, but as it's not too large, I included everything. -Thufir -- gentoo-user@gentoo.org mailing list
[gentoo-user] Autofs problem 4.1.3-r4
Hi all, having a terrible problem with autofs which I already had a couple months ago (wierd isn't fixed). When I start autofs I get: /home/usr/bin/automount: option -t requires a numeric argument, got, intr, nosuid,rsize=8192,wsize=8192. I was able to solve it at some point but now I can't remember how I did it. Does anyone know? Cheers, -- Paulo Jorge Matos - pocm at sat inesc-id pt Web: http://sat.inesc-id.pt/~pocm Computer and Software Engineering INESC-ID - SAT Group -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] autofs + usb device issue
On Fri, 23 Sep 2005 23:33:54 +0200, Pawe__ Madej wrote: > I'll describe my situation: My laptop has only one usb port and > normally I have plugged to it my mouse. When I want to copy photos from > my digital camera I have to unplug mouse and plug usb cable to camera. Wouldn't it be easier to buy a small USB hub? > 1. I plug camera and I got it under /dev/sda1 device > 2. I unplug it and plug once more ... this time it is the > same /dev/sda1 device > 3. I uplug it once more and plug my mouse and unplug it > 4. I plug my camera and this time it is under /dev/sdb1 device Use udev to set up persistent device names, base don the device itself, not when it was plugged in. Then your camera would always appear as /dev/camera, or whatever name you choose. Read http://www.gentoo.org/doc/en/udev-guide.xml then follow the link to writing udev rules at the bottom. -- Neil Bothwick Normality is restored. Any problems remaining are your own. pgpkTJHm6anLR.pgp Description: PGP signature
[gentoo-user] autofs + usb device issue
Hello, I've installed and configured automounter and it works ok for my cdrom and floppy drive. I'll describe my situation: My laptop has only one usb port and normally I have plugged to it my mouse. When I want to copy photos from my digital camera I have to unplug mouse and plug usb cable to camera. 1. I plug camera and I got it under /dev/sda1 device 2. I unplug it and plug once more ... this time it is the same /dev/sda1 device 3. I uplug it once more and plug my mouse and unplug it 4. I plug my camera and this time it is under /dev/sdb1 device What is the problem? How to configure /etc/autofs/auto.auto to automount camera to the sane directory inspite of device which it is recognized. I tried like that: camera -fstype=vfat,rw :/dev/disk/by-id/usb-OLYMPUS_C750UZ_000262018416-part1 whole is on one line this usb-* links to the actually recognised device (sda1 or sdb1) when i plug my camera) but autofs will mount camera only once and after device changed it wont mount it anymore until I restart autofs daemon. Thanks for any help Pawel -- gentoo-user@gentoo.org mailing list
