Okay, well ... this is still fun with bash + bash aliases and also involves running a script with an alias, so putting it up here.
In another tute, figured out a way to auto run a script when a usb thumb drive is un/plugged by using a udev rule and started messing around with ways to get it to automatically run a bash script that will rsync the contents of a target directory to that thumb drive, while I'm still working on it and may get there someday, cooked up something that's worth sharing on the topic.
Was getting real frustrated with the situation, playing around with a bash script (and my bash skills suk!) The stupid needing priv's to even mount the usb drive, this that ... other BS !!! ARGHHHH ! So googled, came across a common sense suggestion, if you're going to use sudo cmds in a script, why not just run the script with sudo ie: "sudo /path/to/scriptname.sh". Yep ... not bad as privileged commands in it are all run with priv's, this would mean only having to enter password the one time. This however isn't what I wanted, fortunately am aware of a cool nix trick for this. A person can create a file at the following, /etc/sudoers.d and enter commands they wish to run as sudo but w/o password, clearly this is to be used with common sense and caution. Anyway ... I created a file there named myrules and added this as what's relevant to what's being discussed here.
Code: Select all
# Stuff I don't want to enter passwd to run/use.
yourusername ALL=(ALL) NOPASSWD: /usr/local/bin/backup.sh
Edit: Had to correct an oversight in the example of the /etc/sudoers.d/myrules file. Dang it, example is good to go now. Though this is one of the reasons I keep a root user acct around. Syntax mistakes in those sudoers.d files or if someone messes up the /etc/sudoers file itself with direct editing can break sudo, sudo cmds won't work and that can leave someone in a bad situation if they don't know how easy it is to fix. aka: Chroot an ailing system from live session and fix it.
In my case, with a root user, even if sudo gets borked, I just have to "su -" login as root and then can quickly fix such a syntax error to restore sudo. So if I'm in a hurry and break sudo by making a mistake in such a file, takes less than 1min to fix it. So I quit worrying about visudo long ago. While doing this edit may as well do it right, actually these files are supposed to be edited by using visudo. An example of doing that here would be "sudo visudo -f /etc/sudoers.d/myrules" it'll open that file using visudo, then if I change it and have messed up syntax, put a comma in the wrong place etc etc, when I go to save the file visudo will tell you there's a problem. Someone can just back-out of applying the changes, like closing the terminal or whatever w/o those errors being written. Google if you desire further info on using visudo and about sudoers.d.
Of course you can add more, just separate them adding a ,(comma)to the end of the last entry, then a space and add the next, no comma at the end/last one needed. What the above does is let me run the following in terminal w/o passwd needed "sudo /usr/local/bin/backup.sh" Next up we need a backup.sh file (a script) at that location, let's make it, in terminal "sudo touch /usr/local/bin/backup.sh" which creates that file, then "sudo chmod +x /usr/local/bin/backup.sh" makes it executable and from here would say open the file in a graphical text edit with sudo/root priv's so you can copy/paste what's coming up. Wait a minute before doing that.
Couple other things first, we're going to create a mount point to mount the thumb drive to when the script is run, do so with "sudo mkdir -p /mnt/usb" it creates a directory at /mnt/usb which is going to be the mount point used for this, of course peeps are free to use another location-name etc. Though /mnt is totally appropriate for this type of thing.
Plugin the thumb drive you wish to use here, we need to get the UUID of the partition on it we're going to use in the script, that's persistent across reboots, get this info by running "sudo blkid" take note of the UUID needed. In my case that's sdc1, the 1st partition on the thumb drive. ie:
Code: Select all
/dev/sdc1: UUID="7a04842f-2005-26cd-8489-09c437d410ac"
Getting there, now for opening the backup.sh script as sudo/root, in a graphical editor or command-line editor if you like ... Here's my script contents by way of example.
Code: Select all
#!/bin/bash
sudo mount -t ext2 /dev/disk/by-uuid/7a04842f-2005-26cd-8489-09c437d410ac /mnt/usb
sudo -u yourusername rsync -aAX /mnt/data/newstufftosave/ /mnt/usb/test/
sudo umount /dev/disk/by-uuid/7a04842f-2005-26cd-8489-09c437d410ac ;
exit
Gawd, now have to explain all that, 1st off something of note in the beginning of it, the "mount -t ext2" that's because my thumb drive is formatted as ext2, because it respects gnu/Linux file permissions etc etc. Now you likely have a fat32 formatted usb drive which is fine too, use "mount -t auto" instead of what I've got. /dev/disk/by-uuid/YOURUUID is where the script is targeting the usb drives partition I'm using here, plugin your drive, open a file manager and click your way into that location, you'll find your thumb drive there, though with its UUID, not mine or the one I'm using in the example above.
You can unmount and remove your thumb drive a bunch of times and check again, n again n again etc. Try some different usb ports too. Yep you'll notice your thumb drive keeps popping up there and its UUID is the same, now getting back to it ... That first line is just mounting the thumb drive based on its UUID to the chosen mount point = /mnt/usb the next line is important (for me, as again I'm using a filesystem which cares about ownership/permissions) the "sudo -u username" runs the rest of that, the rsync command as that user, so I don't have to worry about ownership-etc being changed to root when the stuff is copied by rsync to the thumb drive, in your case go ahead and use it, won't matter regardless, though not using it can depending on the filesystem you want to copy this stuff to, /mnt/data/newstufftosave/ is the source directory, it's where rsync is going to copy everything from and in my case /mnt/data is a shared ext4 data partition I've got setup to automount in /etc/fstab, again newstufftosave is just a directory on that shared data partition.
The destination directory is /mnt/usb/test/ a directory named test on the thumb drives partition, though actually rsync will create it for you w/o having to do so ahead of time. The IMPORTANT thing here is be sure you use the right paths for the source and destination. Shew, alright ... almost done, the "sudo umount" is just unmounting the thumb drive from /mnt/usb the ; is just like typing & and finally the next line ... exit, does that, exits the dang script. Clearly after you've changed things to fit your system, UUID, filesystem you're using, username etc. Save the backup.sh ... NOTE: See ps2 edit post below, if you're using fat32.
Last up here, time to add an alias, as outlined in the tute above this one, if you've got a .bash_aliases file in /home and the command-line text editor nano installed on your OS run "nano .bash_aliases" Otherwise open the .bash_aliases file with a graphical editor of choice, this is the alias I added.
Code: Select all
# Alias to rsync backup files to thumb drive.
alias usbbk='sudo /usr/local/bin/backup.sh'
And there you have it, in future, when I add or change files in that source directory, can just plugin my thumb drive, pop open a terminal and run the alias shown "usbbk" and rsync will dutifully copy stuff over to the thumb drive for me. WOOT ! Pretty cool stuff. Not quite as cool as all this happening automagically when a certain usb drive is plugged but none to shabby either.
Ps, Holy crap, gonna have to start putting chapters n page numbers in these monsters. There's another gd tute though.