Ubuntu technical problems and solutions reference, a modern cookbook.
Tag Archives: sudo
February 17, 2013Posted by on
Gpg encryption is cool. It’s so cool, that I want to keep all my important files (that means back-up files) encrypted on my external storage.
Using gpg is fairly straight forward:
1) Generate a private key.
After answering some standard questions, the key is ready.
Note: You better not forget the password you choose, or else your encrypted files are lost forever.
2) Check you key:
This will display a list of all available keys.
3) Encrypt a file
gpg --encrypt --recipient 'key name' foo.txt
This will generate the encrypted file: foo.txt.gpg
4) Decrypt a file
gpg --output foo2.txt --decrypt foo.txt.gpg
foo2.txt file will be created.
So, until now I presented a quick guide to encrypt/decrypt a file. However, this wasn’t enough for me. I wanted to go a little further. I wanted to be able to encrypt folders as well, and the possibility to delete the original file, and keep only the encrypted one. So, I though I write my own function.
And so, tec was born.
In short tec stands for: tar, encrypt, clean. Long description: Tarballs and encrypts the TARGET using gpg (GnuPG) encrypton. Optionally it deletes the TARGET.
Just copy tec.sh into /usr/bin, and you’re good to go.
cd <download directory> sudo cp tec.sh /usr/bin
For general help, type:
# with delete option, to delete the original file, and keep the encrypted one tec.sh -dr <key> <file> # without delete option tec.sh -r <key> <file>
The project is in it’s early phases. Currently it only encrypts. For decryption the standard gpg commands have to be used. I plan to maintain the function, and try to add as much functionality as I can.
September 23, 2012Posted by on
Recently I was faced with a new issue/challenge: adding custom man pages for a custom/user defined command. This being said, I started to dig into the configuration and structure of the man command.
I will not go too deep into the man theory, there is always Google for it, or the official manual pages:
As I now know, after reading documentation, there are 9 section of documentation for each command. So, it means separate documentation file for each section.
In the following example I will create custom documentation for section 1 (Executable user programs and shell commands) and section 4 (Information on device files). I call the command dummy.
#The following commands create the default structure for custom man pages cd ~/ mkdir ownman; mkdir ownman/man1; mkdir ownman/man4 cd ownman/man1 vi dummy.1 # Add some documentation here. Example: 1) Documentation for section 1 cd ../man4 vi dummy.4 # Add some documentation here. Example: 1) Documentation for section 4
Now that the structure is in place, the man pages for the the dummy command can be called. The -M option has to be used in order to specify the location of the man pages for the specific command.
man -M ~/ownman dummy 1) Documentation for section 1 Manual page dummy(1) line 1/66 (END) (press h for help or q to quit)
The default section is 1, so it’s not necessary to be specified here. With specification, the command looks like this:
man -M ~/ownman 4 dummy 1) Documentation for section 4 Manual page dummy(4) line 1/66 (END) (press h for help or q to quit)
The structure and the call is in place now. But still, it could be tiresome sometimes to remember the path to the man pages, especially if one were to declare multiple locations.
To add the ~/ownman location to the locations man is looking at by default, the configuration file needs to be edited. On Ubuntu this file is: /etc/manpath.config (for Red Hat and Red Hat derivatives, like CentOS and Fedora, the configuration file for man is /etc/man.config)
# need sudo rights for this, as the owner of the file is root sudo vi /etc/manpath.config
Edit the file by adding a new entry in the MANDATORY_MANPATH section.
If there is a need to specify different man pages path for different command paths, another edit needs to be made, further down in the file. A new entry for MANPATH_MAP
MANPATH_MAP ~/custom_commands_location ~/ownman
Now the simple, straight forward command can be called:
man dummy 1) Documentation for section 1 Manual page dummy(1) line 1/66 (END) (press h for help or q to quit)
February 13, 2012Posted by on
I found myself recently in the awkward situation of replacing all the groups my user was part of, with a group I wanted to append to.
Due to the fact that I have installed VirtualBox, my user needed to be part of the vboxusers group. All good I thought, so I wanted to add that group to my user.
So I used the following Wrong command
sudo usermod -G vboxusers myuser
As per the help
usermod --help -G, --groups GROUPS new list of supplementary GROUPS -a, --append append the user to the supplemental GROUPS
I have realised that I forgot to add the append option. So actually to add the new group to the existing list of groups.
The correct command would have been:
sudo usermod -aG vboxusers myuser
After my reboot, because the effect of the command is not visible until a logout/login is performed, I have found myself without sudo/admin rights. The result of the command:
was myuser and vboxusers. Great, no admin rights.
So here is what I did to solve this problem.
Boot up from the LiveCD. Hope you have one at hand. Doesn’t have to be the latest distribution.
Open the terminal and mount your root:
sudo mount /dev/sda1/mnt sudo chroot /mnt
Note: instead of sda1 you should use the partition on which your root is mounted. If you are not sure about it, check in Disk Utility application (the default one on your liveCD.
Locate the groups:
The file which holds the groups is simply called group. But because you have recently changed this file with the wrong command, you need to check the backup file in order to determine which were your old groups, so that you can add them back. The backup file is group-.
Now, you have 2 options to go forward. The first one is to manually edit the group file to add your user against the groups (take the back-up file as an example). The second option is to simply re-add the groups to your user with the usermod command. This way you learn the right format of the command:
usermod -aG group user
Note: there is no need to use sudo in a liveCD session.
Now remove the liveCD and the reboot will make you a happy user 🙂
November 13, 2011Posted by on
I know there are a lot of people who are adding their drives in /etc/fstab. I personally don’t like that approach, because in Nautilus I will see 2 copies of the same drive. One mounted and the other unmounted and when it gets pressed I got an error saying that the drive is already mounted.
I prefer a solution where the drive gets mounted exactly as Nautilus does it, when the drive is mounted by simply pressing the unmounted drive.
First we need to find out where each drive is located, so that we know where each drive is located on the disk. Using the following command, we get the desired outcome:
ls /dev/disk/by-label -lah
The output look something like this:
lrwxrwxrwx 1 root root 10 2011-11-13 14:58 Storage -> ../../sda6
Assuming we need to auto mount the drive called Storage, we create it’s mounting point:
sudo mkdir /media/Storage
Now, a script needs to be created which mounts the drive:
vi ~/mountscript.sh .... #!/bin/bash sudo mount /dev/sda6 /media/Storage
Need to make the script executable and then test it
sudo chmod +x mountscript.sh ./mountscript.sh
You will notice that the script requires us to introduce the password. That’s not good when we are going to add this script to be run at start-up. So we need to exclude the 2 commands we are using (mount and the script we’ve just created) from sudo to ask us for the password.
Add this line at the end replacing your user with the name of your own user:
your user ALL=(ALL) NOPASSWD: ~/mountscript.sh, /bin/mount
Now both commands, mountscript.sh and mount are excluded from being prompted a password.