So I got curious about PGP keys and signing and encrypting using them. I managed to figure out how to use the semi-popular gpg4win (the standard windows port of GnuPG) with its built in Kleopatra GUI, Outlook add-ins and all the other fun stuff.
Using gpg from Kleopatra is much more convenient and automated than using gpg from, say, the command line, like many purists would probably recommend, just like the Git purists recommend only committing from the command line (even though the Git gui is way more convenient for diff and history, and so I continue to use it almost exclusively if possible).
Well, what I did not realize up until today was that running gpg from the command line was acting much MUCH differently than when I ran it from Kleopatra. But let's go back in history to describe what I did, what I discovered, and how I rectified the problems I found this morning.
- Getting my new work machine, I immediately installed Windows distribution of git core, which includes my favorite git-gui. This particular version of git (2.13.0.windows.1) completely overhauls the virtual machine folder structure so that rather than running git bash shell from ../Git/bin (a scaled down version of MinGW), it instead runs from ../Git/mingw64/bin/ and ../Git/usr/bin. But that's not the important thing to understand. Rather, what I really didn't understand is that git's mingw comes pre-packaged with gpg. But we're ignoring that so you can re-live my tale of headache.
- Move forward 2 months to when I want to explore gpg for the purposes of signing and encrypting documents, emails, other keys, etc. I installed gpg4win-3.0.0. Kleopatra is a great little gui! I import a few keys to check signatures on things like ubuntu iso files, the actual gpg4win-3.0.0 signature, one I found of a friend (which he confessed he doesn't use anymore). Over time, I accrue over ten keys in my list.
- A few weeks pass. I start reading more, and discover that you can sign git commits!!
Okay, so how do I do this? Well, what if I were to create a new master key and, like I saw a few people doing, label it as "CODE SIGNING KEY?" Sounds pretty reasonable. That I can do without a tutorial in Kleopatra!
Next I head over to https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work. Perfect. I already have the key, but let me do those steps anyway.
From git bash, gpg --list-keys: No default key. Creating pubring.gpg and secring.gpg. Umm..that's odd. Shouldn't the one I just created in Kleopatra be there? Oh well. Let me try this gpg --import EDDD62B2.gpg, since I was careful a month ago to back up public, secret and revocation files. Tried the command again, okay, now it's there.
Changed a file, and from the bash shell, tried git commit -S -m "Test GPG signature": Enter your passphrase. Okay. Did it. Commited! YAY!
Okay, so this will be inconvenient to have to remember the "-S" bit every time I want to do something, plus, hey, if I want to use git-gui, there's no checkbox to sign a commit. Only to add a signature to the commit message (which I verified - "Sign your message" does not gpg sign the commit, even when one is available).
So how do I configure git to force-sign commits? Uhh http://lmgtfy.com/?q=git+force+gpg+signature
Oh this one looks good. Tried the instructions in https://stackoverflow.com/a/20628522/1265581 and sure enough, now git commit -m "Next test gpg signature (should be automatic)" totally asks for my passphrase, and git log --show-signature verifies the signature! Hooray!
So next step, does this work in git-gui? Tried it, uh...no. Big error (which I don't remember). Well, dang. So apparently, I can do all my diffs, my staging, and writing up the commit mess....no wait. Apparently git bash doesn't like a typical right-click/paste. So I have to open git-gui to stage and diff, and git bash AT THE SAME TIME to write the commit message and actually perform the commit. Well. That's not fun. But I'll do it.
- One more week later. I am now working on a hardware controller utility on my laptop. Time to get my secret keys transferred over so I can work from there. Obviously I want to see about getting the new git-gui installed too. Now I have git 1.9.5-preview20150319 installed as a 32-bit program, git 2.15.0.windows.1 installed as a 64-bit program (both of which I STILL did not yet realize had their own versions of gpg.exe). Also I had gpg4win-3.0.0 installed from before, to check whether or not emailing an encrypted message would work properly via the Outlook addin (which it did).
Set it up exactly like I had it on my desktop and....wait, now signing DOESN'T work? What's going on!? So now I'm subjecting myself to workarounds of transferring code via flash drive to a workstation that can properly sign the commits.
Plus I have not yet caught on that there's a reason why running gpg --list-keys is returning only my own keys, while Kleopatra shows over 20 in my list. And why I went through a huge bout of 'why in the world is it saying pubring is down in AppData when on my desktop they're all in ~/.gnupg, which I thought -I- created, but probably didn't?
- On to today. I want to sign and symmetric-encrypt a text document in plaintext (armor) format. While I can do all of the Right Click > Sign and Encrypt from my Windows context menus, it never gives me the armor option. But the binary gpg file it generates will totally decrypt fine in Kleopatra, so it should work in the command line, right?
So I try it in the command line via gpg --encrypt text.txt --armor --symmetric -o test.asc. Okay, this works fine. But then running decrypt from Kleopatra and I get "No valid OpenPGP data found." Uhh...why?
More Google, and I discover http://unix.ittoolbox.com/groups/technical-functional/shellscript-l/unable-to-decrypt-the-file-using-gpg-5012722 one, which offers (in my case) the workaround to add --force-mdc which is some security thing that my version isn't using by default? Well how do I make it by default? Add something to ~/.gnupg/gpg.conf? Well let me see..
It is at this point that something fires in my brain and I think, "wait... does my LAPTOP show all of my gpg keys? Sure enough, they do. All the ones I imported from Kleopatra are visible. But Git does not want to sign any commits with anything I have anyway. That means Kleopatra somehow is reading from its standard pubring (in ~/AppData/Roaming/GnuPG), where as gpg from the command line is reading the pubring from... ~/.gnupg/."
How do I force the command-line version to read from the pubring.kbx file instead of pubring.gpg? Research research research. Environment variables to switch databases...just creates an empty pubring.gpg in the location where pubring.kbx is located. No way I can make it read the kbx file that's already there??
At this point, I read somewhere that 'gpg 2 and up uses the kbx file format, where as versions lower than that use gpg. You will need to do this and this to merge them.' Well what's MY version? 1.4.21. But if I run "C:/Program Files (x86)/GnuPG/bin/gpg.exe" --version, I see 2.2.1! Ohh..so SOMETHING is forcing the Windows command line to use a different, OLDER copy of gpg.exe somewhere, probably out of my path.
A bit of research later and I discover that yes, indeed, Git has its own copy buried down inside of the program directories! Well, can I force git to use the gpg4win version? There's this command I can run to configure git to use it...but it doesn't seem to want to work.
What if I rename ../Git/usr/bin/gpg.exe to gpg.xex? Yep, THAT works then. Now both git bash shell and windows command line use C:/Program Files (x86)/GnuPG/gpg.exe, as does Kleopatra!
But will git sign commits properly? Let's give it a shot. Edit text file, git commit -S -m "Test commit." Asks for passkey. Success! Wonderful! Ooh though now I wonder... what would happen if I tried a commit in git-gui?
Open git-gui, change a file, save, rescan, stage, type message, I know that git is configured to force signatures, so let's just commit...aaaaand popup requesting passkey! EXCELLENT!!
Back out to windows command line and gpg --version. gpg 2.2.1. Excellent AGAIN!
Switch to my laptop. Rename gpg.exe to gpg.xex. And now it reads gpg 2.2.1 in both windows command line and bash shell on both computers! I'll write a blog post before I test whether or not it can now correctly sign commits.
Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts
Linux - find what is preventing you from unmounting a drive
Disclaimer: I've had this problem for probably four months, ever since I started running Plex Media Server on my headless linux machine at home, whilst storing all my actual media on a nice external portable drive. Usually I just yank it, but then I watch the drive letters run themselves up obscenely high before I need to reboot.
So you've gone through the process of mounting your drive in Linux:
> sudo fdisk -l
Device Boot = /dev/sdb1 (and a bunch of other technical information regarding drive size, id, and such)
>
> sudo mount -t ntfs-3g /dev/sdb1 /media/TOSHIBA
>
You run a bunch of stuff, get it all working, then find you need to take the drive to work the next day, so you try to unmount it.
> sudo umount /media/TOSHIBA
umount: /media/TOSHIBA: device is busy.
(In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))
>
Well, being a Windows guy at heart, and not really understanding why everything here needs to be so technical, this message never told me ANYTHING. I would try typing just plain "lsof" or "lsof(8)" or "fuser(1)" with no useful results.
Then I asked a friend.
"lsof | grep <stuff>," he said.
"Like, <stuff> would be the /dev/sdb1?"
"Yeah."
So I tried it:
> sudo lsof | grep /dev/sdb1
mount.ntf 2096 root 3u BLK 8,33 0x1d1ba997e00 2897182 /dev/sdb1
"Oh," he said. "Try the mount path. /dev/sdb1 is the device which is mounted somewhere else."
> sudo lsof | grep /media/TOSHIBA
>
"Nothing," I said. "Just a blank line."
"Looks like no program has any file open on it?"
"Let me try again."
bash 2068 daniel cwd DIR 8,33 8192 17459 /media/TOSHIBA
grep 2254 root cwd DIR 8,33 8192 17459 /media/TOSHIBA
lsof 2255 root cwd DIR 8,33 8192 17459 /media/TOSHIBA
"Ahh...It may have been because I was still cd'd into it."
"Yes!"
So lessons learned:
So you've gone through the process of mounting your drive in Linux:
> sudo fdisk -l
Device Boot = /dev/sdb1 (and a bunch of other technical information regarding drive size, id, and such)
>
> sudo mount -t ntfs-3g /dev/sdb1 /media/TOSHIBA
>
You run a bunch of stuff, get it all working, then find you need to take the drive to work the next day, so you try to unmount it.
> sudo umount /media/TOSHIBA
umount: /media/TOSHIBA: device is busy.
(In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))
>
Well, being a Windows guy at heart, and not really understanding why everything here needs to be so technical, this message never told me ANYTHING. I would try typing just plain "lsof" or "lsof(8)" or "fuser(1)" with no useful results.
Then I asked a friend.
"lsof | grep <stuff>
"Like, <stuff>
"Yeah."
So I tried it:
> sudo lsof | grep /dev/sdb1
mount.ntf 2096 root 3u BLK 8,33 0x1d1ba997e00 2897182 /dev/sdb1
"Oh," he said. "Try the mount path. /dev/sdb1 is the device which is mounted somewhere else."
> sudo lsof | grep /media/TOSHIBA
>
"Nothing," I said. "Just a blank line."
"Looks like no program has any file open on it?"
"Let me try again."
bash 2068 daniel cwd DIR 8,33 8192 17459 /media/TOSHIBA
grep 2254 root cwd DIR 8,33 8192 17459 /media/TOSHIBA
lsof 2255 root cwd DIR 8,33 8192 17459 /media/TOSHIBA
"Ahh...It may have been because I was still cd'd into it."
"Yes!"
So lessons learned:
- grep, no matter how weird and complicated it looks with all those pipes and stuff, is still VERY useful.
- lsof is the command of choice for figuring this out.
- Use the mount point rather than the drive itself when searcing the lsof output text.
- Even just navigating into a drive will lock it from being unmounted - it's not like in Windows where if you "Safely Remove Hardware" or yank the USB cable, the computer conveniently closes the explorer window for you.
Ubuntu Server - Changing Screen Resolution with GRUB2
Recently I drug out my old Dell dinosaur (Dimension) from the closet and decided to try installing Ubuntu server onto it.
Well, all went well until I also attempted to add the Xubuntu-Desktop package, so I could better run around and do things in there. A quick update for an nVidia graphics driver froze the computer directly after login, and all the stuff I found in the forums didn't really help that much, except for possibly uninstalling all the packages that xubuntu-desktop stuck in there. Since there wasn't a lot on there (except for maybe the neat desktop backgrounds that seem to change with every version of any Ubuntu release), I figured a fresh install would be best.
After reinstalling the OS, I did a repository update, which screwed up my screen resolution. My monitor can handle 1280x1024, but the update had changed it to 640x480.
Note: This is Ubuntu Server 10.04.
How do you change screen resolution within a pure terminal interface? GRUB2.
Around version 9.04, Ubuntu upgraded the bootloader from GRUB to GRUB2. This is way more confusing, but can still be figured out.
For the sake of simplicity, there is no longer /boot/grub/menu.lst. It's just not there, nor will it be used if you create it. Instead, all the configurable options are now moved into /boot/grub/grub.cfg
The problem is though, with the command $ sudo update-grub or on a kernel update, this file is overwritten. Therefore, this file should not be editted.
But where does GRUB pull all this information when it DOES do an update?
All the config options are actually stored in the /etc/grub.d folder. This folder are 7 sub-files:
On grub-update, all of these files are executed and mashed together and copied into grub.cfg. But these files don't change ever. Therefore, you can change them yourself, adding entries and such.
I don't know all the details, but the process for adding more operating systems is much more complicated than before. They've decided to use some C-style function for each menu entry, rather than the old way of a simple list with tabbed sub-values.
You can see the way menu items are placed by looking directly at the /boot/grub/grub.cfg file and scrolling down to the 10_linux section.
In mine, a single final entry appears like the following:
All this is somehow scripted into the 10_linux file. You won't see this exact entry anywhere in the file, but instead they've created a way for it to execute a 'find all options and translate them into this format' when you do sudo update-grub.
But anyway, back to the issue at hand. My screen resolution is messed up. I said GRUB2 was the solution to fix this. The options for screen resolutions are stored in /etc/grub.d/00_header.
Open the file in an editor, and scroll down until you see the if statement:
Simply change 640x480 to whatever your desired (and of course, possible) screen resolution is, save, update-grub and reboot.
Oh, and if it matters, a read through the Official Ubuntu GRUB2 Docs might help.
I just now decided to read further into that help file right there...apparently you can also change screen resolution in the /etc/default/grub file, as well as turn on countdowns and things to make sure that you can actually use the menu.
In /etc/default/grub:
GRUB_GFXMODE=640x480 - Change to something your screen can handle and that you want. Maximum is usually okay if you're good on small text. They say in the documentation, that you can comma-separate values also, in case one doesn't work. Just put them in a DESCENDING preferred order, usually high to low.
Also make sure you uncomment the line by removing the # symbol at the beginning of it.
The vbeinfo command in the shell should give you your valid resolutions.
Also, if you find that there is no menu displayed, you can turn on timeouts in this file.
if GRUB_HIDDEN_TIMEOUT is set to something above 0, a message will be displayed on bootup saying something like, "Press any key for the menu..", unless of course, the GRUB_HIDDEN_TIMEOUT_QUIET is set to true. Then you will see a black screen for that amount of time.
If GRUB_HIDDEN_TIMEOUT is empty (GRUB_HIDDEN_TIMEOUT=), GRUB_TIMEOUT will be used instead, and if this is a number greater than 0, the menu will be fully displayed every time you boot up.
Just remember to run sudo update-grub after editing.
Well, all went well until I also attempted to add the Xubuntu-Desktop package, so I could better run around and do things in there. A quick update for an nVidia graphics driver froze the computer directly after login, and all the stuff I found in the forums didn't really help that much, except for possibly uninstalling all the packages that xubuntu-desktop stuck in there. Since there wasn't a lot on there (except for maybe the neat desktop backgrounds that seem to change with every version of any Ubuntu release), I figured a fresh install would be best.
After reinstalling the OS, I did a repository update, which screwed up my screen resolution. My monitor can handle 1280x1024, but the update had changed it to 640x480.
Note: This is Ubuntu Server 10.04.
How do you change screen resolution within a pure terminal interface? GRUB2.
Around version 9.04, Ubuntu upgraded the bootloader from GRUB to GRUB2. This is way more confusing, but can still be figured out.
For the sake of simplicity, there is no longer /boot/grub/menu.lst. It's just not there, nor will it be used if you create it. Instead, all the configurable options are now moved into /boot/grub/grub.cfg
The problem is though, with the command $ sudo update-grub or on a kernel update, this file is overwritten. Therefore, this file should not be editted.
But where does GRUB pull all this information when it DOES do an update?
All the config options are actually stored in the /etc/grub.d folder. This folder are 7 sub-files:
- 00_header
- 05_debian_theme
- 10_hurd
- 10_linux
- 20_memtest86+
- 30_os-prober
- 40_custom
On grub-update, all of these files are executed and mashed together and copied into grub.cfg. But these files don't change ever. Therefore, you can change them yourself, adding entries and such.
I don't know all the details, but the process for adding more operating systems is much more complicated than before. They've decided to use some C-style function for each menu entry, rather than the old way of a simple list with tabbed sub-values.
You can see the way menu items are placed by looking directly at the /boot/grub/grub.cfg file and scrolling down to the 10_linux section.
In mine, a single final entry appears like the following:
menuentry 'Ubuntu, with Linux 2.6.32.32-generic-pae (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os { recordfail insmod ext2 set root='(hd0,1)' search --no-floppy --fs-uuid --set 0689cdb7-786d-4a68-b14b-634b85c9961b linux /boot/vmlinuz-2.6.32-32-generic-pae root=UUID=UUID=0689cdb7-786d-4a68-b14b-634b85c9961b ro quiet initrd /boot/initrd.img-2.6.32-32-generic-pae}
All this is somehow scripted into the 10_linux file. You won't see this exact entry anywhere in the file, but instead they've created a way for it to execute a 'find all options and translate them into this format' when you do sudo update-grub.
But anyway, back to the issue at hand. My screen resolution is messed up. I said GRUB2 was the solution to fix this. The options for screen resolutions are stored in /etc/grub.d/00_header.
Open the file in an editor, and scroll down until you see the if statement:
if [ "x${GRUB_GFXMODE}" = "x" ] ; then GRUB_GFXMODE=640x480 ; fi
Simply change 640x480 to whatever your desired (and of course, possible) screen resolution is, save, update-grub and reboot.
Oh, and if it matters, a read through the Official Ubuntu GRUB2 Docs might help.
I just now decided to read further into that help file right there...apparently you can also change screen resolution in the /etc/default/grub file, as well as turn on countdowns and things to make sure that you can actually use the menu.
In /etc/default/grub:
GRUB_GFXMODE=640x480 - Change to something your screen can handle and that you want. Maximum is usually okay if you're good on small text. They say in the documentation, that you can comma-separate values also, in case one doesn't work. Just put them in a DESCENDING preferred order, usually high to low.
Also make sure you uncomment the line by removing the # symbol at the beginning of it.
The vbeinfo command in the shell should give you your valid resolutions.
Also, if you find that there is no menu displayed, you can turn on timeouts in this file.
if GRUB_HIDDEN_TIMEOUT is set to something above 0, a message will be displayed on bootup saying something like, "Press any key for the menu..", unless of course, the GRUB_HIDDEN_TIMEOUT_QUIET is set to true. Then you will see a black screen for that amount of time.
If GRUB_HIDDEN_TIMEOUT is empty (GRUB_HIDDEN_TIMEOUT=), GRUB_TIMEOUT will be used instead, and if this is a number greater than 0, the menu will be fully displayed every time you boot up.
Just remember to run sudo update-grub after editing.
Subscribe to:
Posts (Atom)