Re: [gentoo-user] Re: samba vs. cifs
Am 17.05.2010 08:56, schrieb KH: On Wed, 05 May 2010 23:20:01 +0200, Matt Harrison wrote about Re: [gentoo-user] samba vs. cifs: >On Wed, May 05, 2010 at 06:42:09PM +0200, KH wrote: [snip] >> specific (don't want to hear "moo"): Will I be able to mount a samba >> partition without setting the samba use flag and after unmerging >> samba? >> >> Regards >> kh > >I just enable cifs in the kernel and install the mount-cifs script. >That lets me mount remote shares with no trouble at all. I don't even install the mount-cifs script. I simply put the share definition in /etc/fstab on the client, and then use the vanilla mount command. E.g., //192.168.0.2/backups /usr/local/remote_backups cifs noauto,noexec,noatime,nodiratime,user=root,pass=eetoot 0 0 [The above should be on 1 line.] Note that my real password for root is not "eetoot"; that is simply a fake password I set up for Samba shares. Whenever I need to transfer a backup archive to the server, I simply issue: mount /usr/local/remote_backups and then copy the data across. Well that didn't look the way I wanted it to look like. Shouldn't be a sig. So again: Hi, just want to answer to that old mail. I have it done as follows: //way/2/otherpc /mnt/mountpoint cifs noatime,credentials=/root/.credentials,uid=1000,umask=000,user 0 0 and the file /.credentials can only be read by root. In there is my password and username: username=myusername password=mypswd Regards kh
Re: [gentoo-user] Re: X hoggs CPU (xorg-server-1.7.6)
One other thing:
# hal-device|grep -C 10 \,ru
net.linux.ifindex = 1 (0x1) (int)
23: udi =
'/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input'
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'input' (string)
input.device = '/dev/input/event2' (string)
input.product = 'AT Translated Set 2 keyboard' (string)
info.addons.singleton = { 'hald-addon-input' } (string list)
input.xkb.rules = 'xorg' (string)
* input.xkb.model = 'pc104' (string)
input.xkb.layout = 'en_US,ru' (string)
input.xkb.variant = ',winkeys' (string)
input.x11_driver = 'evdev' (string)*
info.subsystem = 'input' (string)
input.originating_device =
'/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string)
info.product = 'AT Translated Set 2 keyboard' (string)
info.udi =
'/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input'
(string)
linux.sysfs_path =
'/sys/devices/platform/i8042/serio0/input/input2/event2' (string)
info.parent =
'/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string)
input.xkb.options = 'grp:shift_toggle,grp_led:scroll' (string)
info.category = 'input' (string)
Perhaps HAL is responsible for generating the log messages?
Amit
On 05/17/10 09:42, Amit Dor-Shifer wrote:
# print modification TSs, to verify log refers to said conf file
# stat -c %y /etc/X11/xorg.conf /var/log/Xorg.0.log
2010-05-16 11:01:33.231512534 +0300
2010-05-16 12:23:02.502995953 +0300
On 05/16/10 22:15, walt wrote:
On 05/16/2010 01:12 AM, Amit Dor-Shifer wrote:
Explicitly setting Driver to "evdev" (to both mouse and keyboard
sections) doesn't
> fix the unexplained messages in Xorg.0.log. At least X manages to
start, though.
I'm expecting that your newest Xorg log will be different from the
earlier ones.
Which messages do you mean?
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc104"
(**) Option "xkb_layout" "en_US,ru"
(**) Option "xkb_variant" ",winkeys"
(**) Option "xkb_options" "grp:shift_toggle,grp_led:scroll"
That quite the same as those I had in the beginning.
I'm now noticing another problem: X's CPU usage sky-rockets when
using input devices.
> Especially mouse: If I move my pointer around the screen, hovering
over some windows
> in the process, I get >50% CPU in 'top'.
I've never seen that before. Does hovering over xev print any messages?
Well, I'm less inclined to think now that X is responsible for the
high CPU load. I wasn't too knowledgeable about the relationships
between X and its clients when I made my initial assumption. It was
more like "I startx + I move mouse + CPU shoots-up => it's X".
Looks more like kde is rocking my CPU. Indeed, xev doesn't print
anything while I'm generating high CPU with mouse movements. Also, I
had a notion twm didn't exhibit the phenomenon as long as I didn't
execute any kde apps. But I'm not 100% sure about the latter experiment.
I'm runing KDE 3.5.10.
Amit
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 17 May 2010 11:21:50 +0930, Iain Buchanan wrote: > Well, it turns out I have the distfiles mounted with --bind to my > ftp/pub directory. And looking in the rsync man page: Why not set $DISTDIR to the true location of distfiles instead of using bind mounts? -- Neil Bothwick Tribble math: * + * = *** signature.asc Description: PGP signature
[gentoo-user] Re: Kernel upgrade and now LUKS failure
Am 16.05.2010 14:36, schrieb Jan Engelhardt: > [Replying to > http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 > ] > > In my personal opinion, both the quality of shell commands and key > generation is suboptimal. What makes it bad is that people follow > it. > > First, it generates a key which does not exploit the entire space. > People claim it's because they want an ASCII readout, but frankly, > you get the same with `hexdump -C`. > > Second, it's using echo without the -n parameter, thus implicitly > inserting a newline into the key -- which is the cause for yoru > observed mounting problems. > > Third, because you are passing the key via stdin into cryptsetup, it > only uses the first line of whatever you pipe into it; whereas > pam_mount uses the entire keyfile as it is supposed to be. > > (Fourth, the howto suggests ECB, which, well, looks rather weak > considering the ECB's Tux picture on Wikipedia.) > > All of that should be in doc/bugs.txt, and mount.crypt even warns > about ECB. You really cannot ignore seeing that. > > Phew! Jan, thanks for your suggestions. I created a new LUKS-volume and tried to avoid all the mentioned pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here. The new volume is not mounted with pam_mount-2.1, but mounted OK with pam_mount-1.33. And, btw, as mentioned in the original thread, I use CBC, not ECB ;-) -- Your CCing Daniel didn't work maybe, wrong address, I corrected it for this reply) -- I CC: ha...@gentoo.org to link to the gentoo bug http://bugs.gentoo.org/show_bug.cgi?id=318865 Thanks, regards, Stefan
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 17 May 2010 10:10:02 +0200, Neil Bothwick wrote about Re: [gentoo-user] [SOLVED] identical drives, different free space!: >On Mon, 17 May 2010 11:21:50 +0930, Iain Buchanan wrote: > >> Well, it turns out I have the distfiles mounted with --bind to my >> ftp/pub directory. And looking in the rsync man page: > >Why not set $DISTDIR to the true location of distfiles instead of using >bind mounts? Because binding the directory to /home/ftp/pub makes the distfiles available to the rest of one's network via anonymous ftp. I do the same thing here, without the "pub" subdirectory, and exclude /home/ftp/ from my backups. -- Regards, Dave [RLU #314465] == dwn...@ntlworld.com (David W Noon) == signature.asc Description: PGP signature
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 17 May 2010 12:31:17 +0100, David W Noon wrote: > >> Well, it turns out I have the distfiles mounted with --bind to my > >> ftp/pub directory. And looking in the rsync man page: > > > >Why not set $DISTDIR to the true location of distfiles instead of using > >bind mounts? > > Because binding the directory to /home/ftp/pub makes the distfiles > available to the rest of one's network via anonymous ftp. I do the > same thing here, without the "pub" subdirectory, and exclude /home/ftp/ > from my backups. So the distfiles are actually in /usr/portage/distfiles? I share my distfiles but I don't use FTP as that means storing copies of the same file on each computer. Instead, I use NFS. /mnt/portage is shared across all machines on the network and DISTDIR is set to /mnt/portage/distfiles in each make.conf. Sharing /mnt/portage like this means I can also share my overlay across the network at /mnt/portage/local. -- Neil Bothwick Top Oxymorons Number 18: Taped live signature.asc Description: PGP signature
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 2010-05-17 at 09:07 +0100, Neil Bothwick wrote: > On Mon, 17 May 2010 11:21:50 +0930, Iain Buchanan wrote: > > > Well, it turns out I have the distfiles mounted with --bind to my > > ftp/pub directory. And looking in the rsync man page: > > Why not set $DISTDIR to the true location of distfiles instead of using > bind mounts? because /usr/portage/distfiles IS the real location, and /home/ftp/pub/gentoo/distfiles is the ftp shared location. vsftpd doesn't handle symlinks, so I have to bind it. Now that you mention it though, I could move it for real into /home/ftp/pub/gentoo/distfiles and change DISTDIR... hm. -- Iain Buchanan Real programmers don't bring brown-bag lunches. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 2010-05-17 at 12:39 +0100, Neil Bothwick wrote: > On Mon, 17 May 2010 12:31:17 +0100, David W Noon wrote: ... > So the distfiles are actually in /usr/portage/distfiles? for me yes, it looks the same for David. > I share my distfiles but I don't use FTP as that means storing copies of > the same file on each computer. Instead, I use NFS. /mnt/portage is > shared across all machines on the network and DISTDIR is set > to /mnt/portage/distfiles in each make.conf. > > Sharing /mnt/portage like this means I can also share my overlay across > the network at /mnt/portage/local. Until I pick up my laptop and drive to work, where network speeds to my server drop from 100Mbit to 50kbit and I need that local copy! Which is why I'm glad there are multiple ways to do it :) -- Iain Buchanan Old robot: I choose to believe what I was programmed to believe.
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 17 May 2010 21:50:28 +0930, Iain Buchanan wrote: > > I share my distfiles but I don't use FTP as that means storing copies > > of the same file on each computer. Instead, I use NFS. /mnt/portage is > > shared across all machines on the network and DISTDIR is set > > to /mnt/portage/distfiles in each make.conf. > Until I pick up my laptop and drive to work, where network speeds to my > server drop from 100Mbit to 50kbit and I need that local copy! I tend not to run emerges when away from home, although the lack of a local copy does prove awkward after a kernel upgrade that requires a rebuild of the wireless drivers. Not a situation I have to deal with any more, thankfully. > Which is why I'm glad there are multiple ways to do it :) Indeed :) -- Neil Bothwick A chicken is an egg's way of producing more eggs. signature.asc Description: PGP signature
Re: [gentoo-user] Re: X hoggs CPU (xorg-server-1.7.6)
On 05/17/10 09:42, Amit Dor-Shifer wrote: Well, I'm less inclined to think now that X is responsible for the high CPU load. I wasn't too knowledgeable about the relationships between X and its clients when I made my initial assumption. It was more like "I startx + I move mouse + CPU shoots-up => it's X". Looks more like kde is rocking my CPU. Indeed, xev doesn't print anything while I'm generating high CPU with mouse movements. Also, I had a notion twm didn't exhibit the phenomenon as long as I didn't execute any kde apps. But I'm not 100% sure about the latter experiment. I'm runing KDE 3.5.10. Amit a. I had the "nv" driver instead of the "nvidia" driver loaded. b. openGL was assigned to xorg. 'eselect opengl set' to nvidia fixed that. X still goes as high as 30%. Still looks suspicious, but more acceptable. Amit
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 17 May 2010 13:50:02 +0200, Neil Bothwick wrote about Re: [gentoo-user] [SOLVED] identical drives, different free space!: >On Mon, 17 May 2010 12:31:17 +0100, David W Noon wrote: > >> >> Well, it turns out I have the distfiles mounted with --bind to my >> >> ftp/pub directory. And looking in the rsync man page: >> > >> >Why not set $DISTDIR to the true location of distfiles instead of >> >using bind mounts? >> >> Because binding the directory to /home/ftp/pub makes the distfiles >> available to the rest of one's network via anonymous ftp. I do the >> same thing here, without the "pub" subdirectory, and >> exclude /home/ftp/ from my backups. > >So the distfiles are actually in /usr/portage/distfiles? Correct. >I share my distfiles but I don't use FTP as that means storing copies >of the same file on each computer. Instead, I use NFS. /mnt/portage is >shared across all machines on the network and DISTDIR is set >to /mnt/portage/distfiles in each make.conf. I used to do that, but it meant my NFS server had to be running to perform any software maintenance on any box, so it became a single point of failure. The FTP approach allows each box to be self-reliant. >Sharing /mnt/portage like this means I can also share my overlay across >the network at /mnt/portage/local. My boxes have different stuff in their overlays, and one uses no overlay packages at all. Sharing overlays doesn't make much sense for my set-up. -- Regards, Dave [RLU #314465] == dwn...@ntlworld.com (David W Noon) == signature.asc Description: PGP signature
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
On 05/17/2010 11:14 AM, Stefan G. Weichinger wrote: > Am 16.05.2010 14:36, schrieb Jan Engelhardt: >> [Replying to >> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 >> ] >> >> In my personal opinion, both the quality of shell commands and key >> generation is suboptimal. What makes it bad is that people follow >> it. >> >> First, it generates a key which does not exploit the entire space. >> People claim it's because they want an ASCII readout, but frankly, >> you get the same with `hexdump -C`. >> >> Second, it's using echo without the -n parameter, thus implicitly >> inserting a newline into the key -- which is the cause for yoru >> observed mounting problems. >> >> Third, because you are passing the key via stdin into cryptsetup, it >> only uses the first line of whatever you pipe into it; whereas >> pam_mount uses the entire keyfile as it is supposed to be. >> >> (Fourth, the howto suggests ECB, which, well, looks rather weak >> considering the ECB's Tux picture on Wikipedia.) >> >> All of that should be in doc/bugs.txt, and mount.crypt even warns >> about ECB. You really cannot ignore seeing that. >> >> Phew! > > Jan, thanks for your suggestions. > > I created a new LUKS-volume and tried to avoid all the mentioned > pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here. > > The new volume is not mounted with pam_mount-2.1, but mounted OK with > pam_mount-1.33. > > And, btw, as mentioned in the original thread, I use CBC, not ECB ;-) > > -- Your CCing Daniel didn't work maybe, wrong address, I corrected it > for this reply) > > -- I CC: ha...@gentoo.org to link to the gentoo bug > > http://bugs.gentoo.org/show_bug.cgi?id=318865 > > Thanks, regards, Stefan > Hello :) In a more general discussion I wonder what the advantage of using a SSL encrypted key for HDD-encryption is. As the SSL-keyfile is as well protected as the password to decrypt it is "difficult", so would be a directly encrypted HDD with the same password - or not? If this assumption is correct, then I think the direct approach would be better, as in "less complexity - less errors". I think it is much easier to hide a trojan/keylogger on an unencrypted root-partition than in an initramfs - and not be detected. (Both is easy to do, but the latter can be detected easier.) Unfortunately that detection is never done... after opening the root-dev some form of file-/partition-manipulation check should run. Though the kernel could be already compromised... Only a secure boot-path like with TCG is really secure... well this is only if you fear strong attackers, and not only loosing your notebook :) I head that really strong attackers would hide a keylogger beneath your keyboard... but if you have that kind of opponent, then you really have other problems too :) Anyway - if your /tmp is not encrypted you should put it on a ram-disk: gives you speed and privacy in case of robbery. Also important is to have the screensaver lock the screen. On a technical note: I use "xts" as I read it's a good (although new) algo. Bye, Daniel BTW: No need to CC mailing list mails to me - I'll read and reply the ML-thread when I have time :) -- PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get # gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887 signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 17 May 2010 19:33:18 +0100, David W Noon wrote: > >I share my distfiles but I don't use FTP as that means storing copies > >of the same file on each computer. Instead, I use NFS. /mnt/portage is > >shared across all machines on the network and DISTDIR is set > >to /mnt/portage/distfiles in each make.conf. > > I used to do that, but it meant my NFS server had to be running to > perform any software maintenance on any box, so it became a single point > of failure. The FTP approach allows each box to be self-reliant. Fair comment. I have DISTDIR on my mail server, so if that goes down, I've more to worry about that a few tarballs. Even if it is inaccessible, the other computers would simply download the files to the local directory. > >Sharing /mnt/portage like this means I can also share my overlay across > >the network at /mnt/portage/local. > > My boxes have different stuff in their overlays, and one uses no > overlay packages at all. Sharing overlays doesn't make much sense for > my set-up. It makes sense for me because everything is in one place, making maintenance and backups simpler. Even if a package is only used on one computer, for now, a central location still makes sense. -- Neil Bothwick The computer revolution is over. The computers won. signature.asc Description: PGP signature
Re: [gentoo-user] [SOLVED] identical drives, different free space!
On Mon, 2010-05-17 at 21:53 +0100, Neil Bothwick wrote: > On Mon, 17 May 2010 19:33:18 +0100, David W Noon wrote: > > > >I share my distfiles but I don't use FTP as that means storing copies > > >of the same file on each computer. Instead, I use NFS. /mnt/portage is > > >shared across all machines on the network and DISTDIR is set > > >to /mnt/portage/distfiles in each make.conf. > > > > I used to do that, but it meant my NFS server had to be running to > > perform any software maintenance on any box, so it became a single point > > of failure. The FTP approach allows each box to be self-reliant. > > Fair comment. I have DISTDIR on my mail server, so if that goes down, > I've more to worry about that a few tarballs. Even if it is inaccessible, > the other computers would simply download the files to the local > directory. > > > >Sharing /mnt/portage like this means I can also share my overlay across > > >the network at /mnt/portage/local. > > > > My boxes have different stuff in their overlays, and one uses no > > overlay packages at all. Sharing overlays doesn't make much sense for > > my set-up. > > It makes sense for me because everything is in one place, making > maintenance and backups simpler. Even if a package is only used on one > computer, for now, a central location still makes sense. > As an alternative check out http-replicator - yes the clients do download to a local directory but that can be cleaned afterwards. It also allows download locally when you know you are taking the machine (laptop?) elsewhere. An advantage over NFS is it seems to handle parallel downloads of the same file so you can transparently build all machines in parallel without the downloads stepping on each other over a common NFS mount. I also use a tmfs store for distfiles on one machine with plenty of ram so thats a self-cleaning (on reboot :) alternative. I have used NFS as well and its ok for data stores http-replicator is much better. Beware - NFS can be slow and flakey if used for building over (/var/tmp/portage). The great thing about gentoo's build system is its so flexible! BillK
