W: best way to clone server data using rsync
Hi list I'm about to clone 1TB of server data to a new file server I'm building. Cloning will happen over the internal network, and it will take several days, since I'll only run it while I'm awake/at home and checking up on the progress every once in a while. rsync seems like the right choice, but how will it handle job canceling when I'm done for the day? - will it resume files properly? - will it run some sort of check sum to verify file integrity, or will I have to run myself an integrity check like md5sum afterwards? What's the right set of parameters to call rsync from a shell script? I'm not used to sync such huge amount of files and directories, so I'm unclear about how to call rsync in this case. Here's what I got so far from google research: rsync --sockopts=SO_SNDBUF=128000,SO_RCVBUF=128000 -e rsh --archive \ --recursive --partial --partial-dir=rsync-part --progress --append \ --files-from=/root/LISTOFFILES.txt --log-file=/root/rsync.log \ root@myserver:/PATH2myOLDServerPool/* /mnt/Mount2myNewServerPool LISTOFFILES.txt was created using: rsync --list-only /root/LISTOFFILES.txt Can somebody comment on the parameters, e.g. how these will work fine with job canceling and how this will handle file integrity? Is it safe to hit ctr+c to cancel the job, or is a SIGHUP to the rsync task the recommended/necessary way? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp1800d3c7368bd6ddb7b248cd8...@phx.gbl
Re: W: best way to clone server data using rsync
I noticed rsh is not installed, it's linked to /etc/alternatives/rsh, which is linked to /usr/bin/ssh. Calling rsh instead of ssh should avoid file encryption during transfer, at least that was the intention. The socket options boost transfer speed quite a lot, I usually have 65355 buffers on my samba server, using rsync directly I can increase it some more. partial-dir does not work along with append, so I got rid of it. I'll leave the rest as is minus the recursive option Thanks for the inputs! On 01.05.2012 18:43, Dan Ritter wrote: On Tue, May 01, 2012 at 01:08:14PM +0200, Tuxoholic wrote: Here's what I got so far from google research: rsync --sockopts=SO_SNDBUF=128000,SO_RCVBUF=128000 -e rsh --archive \ --recursive --partial --partial-dir=rsync-part --progress --append \ --files-from=/root/LISTOFFILES.txt --log-file=/root/rsync.log \ root@myserver:/PATH2myOLDServerPool/* /mnt/Mount2myNewServerPool You don't need the sockopts. -a includes recursive. You probably don't want partial or partial-dir. You probably don't want append. Having rsh installed is a bad security risk. Install ssh, make sure you can ssh from this box to myserver as root. Change -e rsh to -e ssh. -dsr- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp363466e7fa2c0053691fdd4d8...@phx.gbl
How /etc/hosts.allow /etc/hosts.deny and smb.conf play along
hi list Can somebody explain why smbd and nmbd are not affected by the following strict ruleset in /etc/hosts* ? /etc/hosts 127.0.0.1 MYHOSTNAME localhost.localdomain localhost 127.0.1.1 MYHOSTNAME 192.168.2.10MYSERVER cat /etc/hosts.allow #ALL: localhost 127.0.1.1 192.168.2.0/24 ALL: localhost 127.0.1.1 192.168.2.0/32 /etc/hosts.deny ALL: ALL With this ruleset in place nmbd broadcasts still pull through and cifs mounts are still possible, whereas ssh/rsh access is no longer possible. To get rid of nmbd/smbd access I have to tweak smb.conf additionally: /etc/samba/smb.conf [global] bind interfaces only = Yes interfaces = 127.0.0.0/8, eth0 ;; hosts allow = 192.168.2.0/24, 127. hosts allow = 192.168.2.0/32, 127. hosts deny = ALL With this smb.conf tweaking it works fine, but why could smbd/nmbd run past /etc/hosts.allow and /etc/hosts.deny without those lines in smb.conf? To my limited CIDR understandig a /32 mask should restrict access to 192.168.2.0.0 and 192.168.2.1 - this should be fine for testing purposes. Once this denies all services I'd set it to /24 to have access to the whole subnet from 192.168.2.0-192.168.2.255 and 127.0.0.1 127.0.1.1 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp149485f83cd3709473ea7d5d8...@phx.gbl
Re: ssh: no route to host
@Hugo: It might be related to your /etc/hosts.allow /etc/hosts.deny configuration. With DHCP your internal subnet should not change. You can use this to set up an access rule for sshd - please refer to the debian administrators guide [1] on securing ssh access for the details. I'll only give the most likely setup for your laptop: In /etc/hosts.allow you set up an access allow rule for your local subnet (192.168.1.xxx) - please not this rule will only affect the ssh daemon: # /etc/hosts.allow sshd: 192.168.1.0/24 sshd: localhost In /etc/hosts.deny I recommend you deny any other sshd access for maximum security: # /etc/hosts.deny sshd: ALL That should be it - now it shouldn't matter anymore what ip address you dhcp server has offered you, as long as it puts you into the same subnet. [1] http://www.debian-administration.org/articles/87 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp4e24951a7dc2d8c6e47c2d8...@phx.gbl
Re: Re: Can't get XVideo to work on squeeze
Walter Hurry wrote: I suspected that the problem was the kernel modesetting, but when I tried with the nomodeset parameter it didn't seem to make a difference. Does this get nearer to identifying the issue? Thanks again. You've cut away the loading cycle of libextmod.so - this does handle the extension loading incl. xv. It should look like this: (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.6, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource Your chipset is AMD 780G, it's well covered by the squeeze xorg ati driver - you might run into problems with an unsucessfull deinstallation of fglrx (ati proprietary driver, if you previously installed that one) or if you still use a xorg.conf. I suggest you keep KMS running if your system supports it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp2104eb2fa4427fddfdb4eced8...@phx.gbl
Re: Can't get XVideo to work on squeeze
Walter Hurry wrote: Here is the extmod part: -- (--) PCI:*(0:1:5:0) 1002:9612:1025:028d ATI Technologies Inc RS780M/ RS780MN [Radeon HD 3200 Graphics] rev 0, Mem @ 0xc000/268435456, 0xd220/65536, 0xd210/1048576, I/O @ 0x7000/256 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource -- I have never installed/uninstalled fglrx, and do not have an xorg.conf. As you recommended, I have reinstated KMS. Where do I go from here? Looks like you are just missing the small firmware blob for the rs780 chipset - you'll find it in the nonfree squeeze repository: http://packages.debian.org/squeeze/firmware-linux-nonfree *) add non-free to your repository lines in /etc/apt/sources.list *) aptitude update aptitude install firmware-linux-nonfree Restart X, you'll notice in Xorg.0.log the small firmware binary for rs780 chipsets is mentioned as now being loaded, xv should be working then. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp1274b5be4526b092153d92fd8...@phx.gbl
Re: Can't get XVideo to work on squeeze
Xorg does load the X-VIDEO extension, so whatever went wrong caused an (EE) line in /var/log/Xorg.0.log - what does this line say? I'm having difficulty getting gxine et al to use Xv. Googling has provided some information, but not a solution. I'm running Squeeze 64 bit. walterh@saturn:~$ xvinfo X-Video Extension version 2.2 screen #0 no adaptors present -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp6954ca49d0e3e8f571a230d8...@phx.gbl
Re: udev rules for 2 identical webcams + 1 spare cam
Von: Camaleón noela...@x.xxx
What do you mean ? - SYMLINK+=webcam%n ? I tried that, didn't help.
Nope.
I wanted to know why you used Name=video%n instead Name=video1 and
Name=video2 in two separate rules/lines.
I see your point, so I tried this:
$ cat /etc/udev/rules.d/10-webcam.rules:
SUBSYSTEM==video4linux, ATTRS{idVendor}==0c45, \
ATTRS{idProduct}==62c0, Name=video0, GROUP=video
SUBSYSTEM==video4linux, ATTRS{idVendor}==046d, \
ATTRS{idProduct}==08a2, Name=video1, GROUP=video
SUBSYSTEM==video4linux, ATTRS{idVendor}==046d, \
ATTRS{idProduct}==08a2, Name=video2, GROUP=video
$ ls -la /dev/video*
crw-rw+ 1 root video 81, 2 14. Jul 20:40 /dev/video0
crw--- 1 root root 81, 1 14. Jul 20:40 /dev/video1
crw-rw+ 1 root video 81, 1 14. Jul 20:40 /dev/video2
As you can see now it's affecting video1 instead of video2 - this is
reproducible over several boots. It is even worse now, as it affects *one* cam
plugged in as well:
$ ls -la /dev/video*
crw-rw+ 1 root video 81, 0 14. Jul 20:51 /dev/video0
crw--- 1 root root 81, 1 14. Jul 20:51 /dev/video1
crw-rw+ 1 root video 81, 1 14. Jul 20:40 /dev/video2
This is seriously odd: udev is now unable to detect the right amount of
plugged Quickcams - this never happend with 2 rules and video%n syntax.
I still consider it a bug, but I should test this with sth newer than squeeze.
Some more ideas what I can test?
Thanks and regards, Tuxholicd
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp1438e257b3fc4c8899dfe0ed8...@phx.gbl
Re: udev rules for 2 identical webcams + 1 spare cam
Von: Camaleón noela...@x.xxx
SUBSYSTEM==video4linux, ATTRS{idVendor}==046d,
ATTRS{idProduct}==08a2, Name=video%n
Why video%n? Why not using a fixed name for each Logitech webcam?
Just curious O:-)
What do you mean ? - SYMLINK+=webcam%n ? I tried that, didn't help.
The reactived source explains the use of regular expressions in node names:
KERNEL==fd[0-9]*
But SYMLINK+=webcam[1-2]* produced bogus device nodes - unusable. I also
tried the bracket expression without the wildcard. It looks like udev no
longer works this way?
One more source [1] explained udev rules with identical usb devices like this:
SUBSYSTEM==video4linux, SUBSYSTEMS==usb, KERNELS==1-1, \
SYMLINK+=webcam1
SUBSYSTEM==video4linux, SUBSYSTEMS==usb, KERNELS==1-2, \
SYMLINK+=webcam2
I changed the usb path to my needs, but this syntax is no longer working?
Have you tried to enforce the permissions of the webcams
(owner/group/mode)?
I tried to force GROUP=video but didn't help.
Anymore ideas? Should I change the level to sth higher than 10-.rule?
Is it worth filing a bug report against udev?
Regards Tuxoholic
[1] http://somedutch.blogspot.com/2010/01/big-mothers-watching-you.html
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp1520874f51090acd702f5d2d8...@phx.gbl
udev rules for 2 identical webcams + 1 spare cam
Hello list
I'm trying to setup a debian system with two identical Logitech usb webcams
plus one spare cam, the one integrated in my laptop.
The spare cam should remain video0.
The other two webcams should be assigned to video1 and video2 in static way at
best, so if a fourth cam would be assigned, this fourth cam should be video3.
I already figured out idProduct and idVendor of the spare cam and the Logitech
Quickcams using udevadm:
$ cat /etc/udev/rules.d/10-webcam.rules:
SUBSYSTEM==video4linux, ATTRS{idVendor}==0c45, \
ATTRS{idProduct}==62c0, Name=video0
SUBSYSTEM==video4linux, ATTRS{idVendor}==046d, \
ATTRS{idProduct}==08a2, Name=video%n
This produces an occasional permission slip in video2:
$ ls -la /dev/video*
crw-rw+ 1 root video 81, 2 12. Jul 16:15 /dev/video0
crw-rw+ 1 root video 81, 1 12. Jul 16:15 /dev/video1
crw--- 1 root root 81, 2 12. Jul 16:15 /dev/video2
This never happens if I plug in the 2nd Quickcam *after* system bootup, it
only happens when both are already plugged in *while* the system is booting
up.
Any ideas what I can change in the rule? OS in use is Debian 6.02
Thanks and regards Tuxoholic
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp116b985741cbaa091976938d8...@phx.gbl
