Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 20150402_1142-0500, David Wright wrote: > Quoting Paul E Condon (pecon...@mesanetworks.net): > > I read the prior discussion as taking for granted the idea that one > > must have only one method of identifying individual partitions, > ^^^ ^^ > If you're referring to my post (which you quoted), then the opposite > is true. The opening paragraphs argues against LABELs as a panacea, > but later ones (and another posting in this thread) reveal that I use > them routinely in what are the right circumstances for me. > > (With top-posting, it can be difficult to tell precisely what you're > commenting on.) It applied to the whole conversation. At least that > was my intent. > > and > > that that method must be the latest to have arrived on the scene. For > > example, if everyone else in the world accepts your idea that > > LABEL=sda1 on the partition that was /dev/sda1 when Debian was > > installed is something that should *not*be*done*, *then* I can be very > > confident that my disk will not cause problems *because*of*an*identity* > > *clash*. > > That may be true for you personally, but your idea scales up to just > one computer. I have several. So do many others. Any time your LABEL is > "correct", it's redundant, and when it's made "incorrect" by changing > circumstances, it's confusing. > > > The whole scenario is false anyway. Who would let a disk > > arrives at his facility in the hands of a stranger be *mount*ed > > without first putting it in a USB disk carrier and using some system > > tools to take a look at what is recorded on it? And why would I offer > > my disk to anyone without *telling* them how it is labeled? > > Facility? Stranger? In my post I suggested that any one person, who > had taken your advice and LABELled their root partition as "sda1", > might take said drive out of that computer and put it into another one > of theirs, whereupon /dev/disk/by-label will have an entry like this: > > /dev/disk/by-label: > total 0 > lrwxrwxrwx 1 root root 10 Mar 31 13:44 sda1 -> ../../sdb1 > > Confusing, unnecessary, avoidable. To me, very informative of a situation that badly needs fixing by other means. > > > I see the argument here, mine as well as yours, as a clash of wildly > > imaginative false scenarios. > > Summarising: names/labels are important. Advising sda1 as a LABEL is > not a good idea. > > If you want a reference, take a look at RFC1178, page 2: > "Don't overload other terms already in common use." Like, for instance, 'window' ? When was the first use of the word, window, in English according to the OED? How many years was it in common use as referring to a common architectural feature of human habitations? And earlier than OED, there is Dr. Johnson's Dictionary of the English Language, which provides a definition of 'window' that was current in 1755, over two centuries before the UNIX epoch. And then there's Humpty Dumpty's Rule for the definition of any word to consider. ;-) Cheers, and Peace, -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150403011255.gc3...@big.lan.gnu
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
Quoting Paul E Condon (pecon...@mesanetworks.net): > I read the prior discussion as taking for granted the idea that one > must have only one method of identifying individual partitions, If you're referring to my post (which you quoted), then the opposite is true. The opening paragraphs argues against LABELs as a panacea, but later ones (and another posting in this thread) reveal that I use them routinely in what are the right circumstances for me. (With top-posting, it can be difficult to tell precisely what you're commenting on.) > and > that that method must be the latest to have arrived on the scene. For > example, if everyone else in the world accepts your idea that > LABEL=sda1 on the partition that was /dev/sda1 when Debian was > installed is something that should *not*be*done*, *then* I can be very > confident that my disk will not cause problems *because*of*an*identity* > *clash*. That may be true for you personally, but your idea scales up to just one computer. I have several. So do many others. Any time your LABEL is "correct", it's redundant, and when it's made "incorrect" by changing circumstances, it's confusing. > The whole scenario is false anyway. Who would let a disk > arrives at his facility in the hands of a stranger be *mount*ed > without first putting it in a USB disk carrier and using some system > tools to take a look at what is recorded on it? And why would I offer > my disk to anyone without *telling* them how it is labeled? Facility? Stranger? In my post I suggested that any one person, who had taken your advice and LABELled their root partition as "sda1", might take said drive out of that computer and put it into another one of theirs, whereupon /dev/disk/by-label will have an entry like this: /dev/disk/by-label: total 0 lrwxrwxrwx 1 root root 10 Mar 31 13:44 sda1 -> ../../sdb1 Confusing, unnecessary, avoidable. > I see the argument here, mine as well as yours, as a clash of wildly > imaginative false scenarios. Summarising: names/labels are important. Advising sda1 as a LABEL is not a good idea. If you want a reference, take a look at RFC1178, page 2: "Don't overload other terms already in common use." Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150402164232.ga10...@alum.home
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 04/01/2015 11:45 PM, David Wright wrote: > Quoting ~Stack~ (i.am.st...@gmail.com): >> On 04/01/2015 03:27 PM, David Wright wrote: >>> I don't recall seeing you post what you actually put into >>> /etc/crypttab to test PARTUUID, only the erroneous earlier versions >>> where you were still using swap's UUID. >> >> Fair enough. Completely plausible I did something wrong as I haven't >> used PARTUUID's in my /etc/crypttab before. >> >> >> # blkid | grep sda3 >> /dev/sda3: PARTUUID="0003efe2-03" >> >> # grep swap /etc/crypttab >> # swap works. >> #sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 >> /dev/urandom cipher=aes-xts-plain64,size=256,swap >> # swap doesn't work. >> sda3_crypt PARTUUID=0003efe2-03 /dev/urandom >> cipher=aes-xts-plain64,size=256,swap > > How about trying > > sda3_crypt /dev/disk/by-partuuid/0003efe2-03 /dev/urandom > cipher=aes-xts-plain64,size=256,swap Same thing. Systemd.fsck runs on boot and takes ~2 minutes before timing out. Swap is not mounted. :-/ Thanks for the suggestion! signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
Quoting ~Stack~ (i.am.st...@gmail.com): > On 04/01/2015 03:27 PM, David Wright wrote: > > I don't recall seeing you post what you actually put into > > /etc/crypttab to test PARTUUID, only the erroneous earlier versions > > where you were still using swap's UUID. > > Fair enough. Completely plausible I did something wrong as I haven't > used PARTUUID's in my /etc/crypttab before. > > > # blkid | grep sda3 > /dev/sda3: PARTUUID="0003efe2-03" > > # grep swap /etc/crypttab > # swap works. > #sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 > /dev/urandom cipher=aes-xts-plain64,size=256,swap > # swap doesn't work. > sda3_crypt PARTUUID=0003efe2-03 /dev/urandom > cipher=aes-xts-plain64,size=256,swap How about trying sda3_crypt /dev/disk/by-partuuid/0003efe2-03 /dev/urandom cipher=aes-xts-plain64,size=256,swap Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150402044544.gd24...@alum.home
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
I read the prior discussion as taking for granted the idea that one must have only one method of identifying individual partitions, and that that method must be the latest to have arrived on the scene. For example, if everyone else in the world accepts your idea that LABEL=sda1 on the partition that was /dev/sda1 when Debian was installed is something that should *not*be*done*, *then* I can be very confident that my disk will not cause problems *because*of*an*identity* *clash*. The whole scenario is false anyway. Who would let a disk arrives at his facility in the hands of a stranger be *mount*ed without first putting it in a USB disk carrier and using some system tools to take a look at what is recorded on it? And why would I offer my disk to anyone without *telling* them how it is labeled? I see the argument here, mine as well as yours, as a clash of wildly imaginative false scenarios. Peace. On 20150401_1619-0500, David Wright wrote: > Quoting Paul E Condon (pecon...@mesanetworks.net): > > > You can also use disk LABEL=. As implemented, the LABEL is actually > > applied to individual partition. As long as every partition has a > > different LABEL values there is no ambiguity. You only need to have > > unique values for partitions that you feel you will be mounting and > > umounting. Partitions with no LABEL value set never get compared by > > LABEL value. > > That may be a problem for anyone using wheezy as it only appears to > have UUIDs and LABELs, and not PARTUUIDs and PARTLABELs available. > As discussed, only PARTXXXs are persistent. (If ever I let the Debian > installer loose on my labelled swap partition, I have to relabel it > afterwards.) > > > The system has always insisted on setting a unique UUID > > value on every partition. Its done that way because of a design > > decision of Debian developers. > > The world has decided that, not just DDs. > > > But it has a tiny flaw that you can > > avoid by using LABEL values, which YOU can be sure are unique because > > you didn't do repeats, whereas UUIDs are randomly generated and there > > is a tiny, but non-zero chance of repeats for UUIDs. > > Oh, please. "Assuming uniform probability for simplicity, the > probability of one duplicate would be about 50% if every person on > earth as of 2014 owned 600 million GUIDs." (Wikipedia) > > What if you're running a disk farm of several thousand drives? > No, LABELs don't scale well. > > > If I read your message above, you are having trouble understanding how > > to use the UUID/PARTUUID system for identifying partitions on disks. > > I suggest that you don't need to use it, and if you don't use it you > > don't need to understand it. > > That's ok until Debian does something behind your back that catches > you out. For example, GRUB uses UUIDs, whereas I prefer LABELs. But I > have to understand what GRUB/Debian Installer/Upgrade is doing so I > can mitigate the effects. > > > I was once troubled by a similar situation when Debian first started to > > use UUID, until I realized that for some disks, I had no intention > > of ever changing the partion structure that was put there initially. > > Hm. Never say never. Yes. > > > For disks that I did have some special use and some ideas about how > > that special use might change in the future, I put LABEL=... on their > > partitions and used LABEL= paradigm to identify the partitions. This > > is what I do with all my external drives. And I put sticker on the > > outside of the drive enclosure with the LABEL= value written with a > > ball point pen on it. It is my personal responsibility to myself that > > I never put the same LABEL= value on two different disks. > > I agree. All my disks, internal and external are named and labelled > just so. But I have so few, and all in different rôles. If I had lots, > I wouldn't bother. > > > You can even > > put a LABEL= value on the root system disk that is always /dev/sda1 > > during installation. I suggest that you use LABEL=sda1. > > Bad idea. The names should not be loaded with extra meaning. My > partition labelling *is* overloaded: mama01, 02 ... but I'm prepared > to live with the necessary constraints: creating them in the correct > order, and not resizing/creating new partitions afterwards unless I > make a clean sweep of it. > > What if you/(s)he were to take a disk labelled sda1 and put it in > another computer to clone/recover/whatever it. Now it sits in a box > where there's a /dev/sda1 and a /dev/sdb1 but the latter is called > sda1. A recipe for disaster. > > > As I see it, the only benefit that you the user get from using the > > UUID/PARTUUID system is that if some Linux user is browsing through > > the internals of what is written on your disk, he may wonder where > > you got the software to do that and treat you with a little more > > respect. Let me assure you, you are not Rodney Dangerfield > > Eh? A very wild scenario, not to be taken seriously > > Cheers, > David. > >
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 04/01/2015 03:27 PM, David Wright wrote: > I don't recall seeing you post what you actually put into > /etc/crypttab to test PARTUUID, only the erroneous earlier versions > where you were still using swap's UUID. Fair enough. Completely plausible I did something wrong as I haven't used PARTUUID's in my /etc/crypttab before. # blkid | grep sda3 /dev/sda3: PARTUUID="0003efe2-03" # grep swap /etc/crypttab # swap works. #sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap # swap doesn't work. sda3_crypt PARTUUID=0003efe2-03 /dev/urandom cipher=aes-xts-plain64,size=256,swap signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
Quoting Paul E Condon (pecon...@mesanetworks.net): > You can also use disk LABEL=. As implemented, the LABEL is actually > applied to individual partition. As long as every partition has a > different LABEL values there is no ambiguity. You only need to have > unique values for partitions that you feel you will be mounting and > umounting. Partitions with no LABEL value set never get compared by > LABEL value. That may be a problem for anyone using wheezy as it only appears to have UUIDs and LABELs, and not PARTUUIDs and PARTLABELs available. As discussed, only PARTXXXs are persistent. (If ever I let the Debian installer loose on my labelled swap partition, I have to relabel it afterwards.) > The system has always insisted on setting a unique UUID > value on every partition. Its done that way because of a design > decision of Debian developers. The world has decided that, not just DDs. > But it has a tiny flaw that you can > avoid by using LABEL values, which YOU can be sure are unique because > you didn't do repeats, whereas UUIDs are randomly generated and there > is a tiny, but non-zero chance of repeats for UUIDs. Oh, please. "Assuming uniform probability for simplicity, the probability of one duplicate would be about 50% if every person on earth as of 2014 owned 600 million GUIDs." (Wikipedia) What if you're running a disk farm of several thousand drives? No, LABELs don't scale well. > If I read your message above, you are having trouble understanding how > to use the UUID/PARTUUID system for identifying partitions on disks. > I suggest that you don't need to use it, and if you don't use it you > don't need to understand it. That's ok until Debian does something behind your back that catches you out. For example, GRUB uses UUIDs, whereas I prefer LABELs. But I have to understand what GRUB/Debian Installer/Upgrade is doing so I can mitigate the effects. > I was once troubled by a similar situation when Debian first started to > use UUID, until I realized that for some disks, I had no intention > of ever changing the partion structure that was put there initially. Hm. Never say never. > For disks that I did have some special use and some ideas about how > that special use might change in the future, I put LABEL=... on their > partitions and used LABEL= paradigm to identify the partitions. This > is what I do with all my external drives. And I put sticker on the > outside of the drive enclosure with the LABEL= value written with a > ball point pen on it. It is my personal responsibility to myself that > I never put the same LABEL= value on two different disks. I agree. All my disks, internal and external are named and labelled just so. But I have so few, and all in different rôles. If I had lots, I wouldn't bother. > You can even > put a LABEL= value on the root system disk that is always /dev/sda1 > during installation. I suggest that you use LABEL=sda1. Bad idea. The names should not be loaded with extra meaning. My partition labelling *is* overloaded: mama01, 02 ... but I'm prepared to live with the necessary constraints: creating them in the correct order, and not resizing/creating new partitions afterwards unless I make a clean sweep of it. What if you/(s)he were to take a disk labelled sda1 and put it in another computer to clone/recover/whatever it. Now it sits in a box where there's a /dev/sda1 and a /dev/sdb1 but the latter is called sda1. A recipe for disaster. > As I see it, the only benefit that you the user get from using the > UUID/PARTUUID system is that if some Linux user is browsing through > the internals of what is written on your disk, he may wonder where > you got the software to do that and treat you with a little more > respect. Let me assure you, you are not Rodney Dangerfield Eh? Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150401211903.gb21...@alum.home
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
Quoting ~Stack~ (i.am.st...@gmail.com): > On 03/29/2015 07:06 AM, Sven Hartge wrote: > > ~Stack~ wrote: > > > >> One more question if you don't mind: I understand why the encrypted > >> partition UUID is going to change every time, but the physical > >> partition UUID for my /dev/sda3 shouldn't change though. If they are > >> the same systemd.fsck shouldn't have a problem with the physical > >> partition UUID of /dev/sda3, but yet it does (at least for me). So > >> what is the difference between the UUID pointing to /dev/sda3 and the > >> /dev/disk/by-id pointing to /dev/sda3? > > > > Please provide an example of such an UUID and the way you obtained it. > > Greetings Sven, > > So something odd has happened... > > # blkid |grep sda3 > /dev/sda3: PARTUUID="0003efe2-03" > /dev/mapper/sda3_crypt: UUID="f4aad427-3462-4dcf-a40d-617e90a7b1cb" > TYPE="swap" > > # grep sda3 /etc/crypttab > sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 > /dev/urandom cipher=aes-xts-plain64,size=256,swap > > That "PARTUUID" is odd because it used to be a UUID...huh...really not > sure what happened...but I have a guess (below)... I can't work out why your blkid | grep produces so little output. Here's some of mine: wheezy: /dev/sda1: LABEL="gina01" UUID="a854f3b7-4ba1-4fa3-8d43-c150169c91a6" TYPE="ext4" /dev/sda4: LABEL="gina04" UUID="32e87272-a109-46ba-8914-c0b5374cb32e" TYPE="swap" /dev/sdb2: LABEL="mama02" UUID="2013-1105" TYPE="vfat" /dev/sdb4: LABEL="mama04" UUID="8561eb12-3ee8-42e1-a5c7-6d36fea217d3" SEC_TYPE="ext2" TYPE="ext3" jessie: /dev/sda1: LABEL="john01" UUID="53515dcb-96fb-4c28-b456-1efbd1fdac38" TYPE="ext3" PARTUUID="c889c889-01" /dev/sda4: LABEL="john04" UUID="876c1170-c64f-4fdf-aae2-a20e9c4a26f6" TYPE="swap" PARTUUID="c889c889-04" /dev/sdb1: PARTLABEL="EFI" PARTUUID="d01dcc00-c77d-4e35-81d9-6ffc12536839" /dev/sdb2: LABEL="mama02" UUID="2013-1105" TYPE="vfat" PARTLABEL="FAT32" PARTUUID="4123d2d5-b471-405e-90ed-76afea329c13" /dev/sdb4: LABEL="mama04" UUID="8561eb12-3ee8-42e1-a5c7-6d36fea217d3" TYPE="ext3" PARTLABEL="m04" PARTUUID="5fabaa67-6f04-4d59-b797-e6fee7f4d454" I don't suppose it's relevant in your case that wheezy is blind to PARTxxx unlike jessie, so sdb1 doesn't even appear. I prefer the output from /run/udev/data because, though much more voluminous, the labelling is better: S:disk/by-id/ata-ST3000DM001-1E6166_Z1F3FX1E-part4 S:disk/by-id/wwn-0x5000c500642bbfd3-part4 S:disk/by-label/mama04 S:disk/by-partlabel/m04 S:disk/by-partuuid/5fabaa67-6f04-4d59-b797-e6fee7f4d454 S:disk/by-path/pci-:00:1d.7-usb-0:5:1.0-scsi-0:0:0:0-part4 S:disk/by-uuid/8561eb12-3ee8-42e1-a5c7-6d36fea217d3 E:ID_FS_LABEL=mama04 E:ID_FS_TYPE=ext3 E:ID_FS_USAGE=filesystem E:ID_FS_UUID=8561eb12-3ee8-42e1-a5c7-6d36fea217d3 E:ID_PART_ENTRY_TYPE=0fc63daf-8483-4772-8e79-3d69d8477de4 E:ID_PART_ENTRY_UUID=5fabaa67-6f04-4d59-b797-e6fee7f4d454 E:ID_PART_TABLE_TYPE=gpt E:ID_PART_TABLE_UUID=35365a04-6978-4588-9fbe-75c8f3263aba Unlike, say, sba4 and mama04 where the difference is obvious, UUIDs all look alike with a quick glance. > Thus, I would want to point to the partition PARTUUID because (as you > pointed out to me earlier) the swap filesystem is going to change every > time due to urandom and thus the UUID should be changing on every > boot...blkid is probably seeing that this is a ever changing swap > partition and just returning the PARTUUID for me. I don't think it's blkid's prerogative to interpret the information, but just to present it. > But putting that PARTUUID in my /etc/crypttab didn't work and I ended up > with the systemd.fsck timing out and not mounting swap. Hrm. I don't recall seeing you post what you actually put into /etc/crypttab to test PARTUUID, only the erroneous earlier versions where you were still using swap's UUID. Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150401202758.ga21...@alum.home
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 20150331_1923-0500, ~Stack~ wrote: > On 03/29/2015 07:06 AM, Sven Hartge wrote: > > ~Stack~ wrote: > > > >> One more question if you don't mind: I understand why the encrypted > >> partition UUID is going to change every time, but the physical > >> partition UUID for my /dev/sda3 shouldn't change though. If they are > >> the same systemd.fsck shouldn't have a problem with the physical > >> partition UUID of /dev/sda3, but yet it does (at least for me). So > >> what is the difference between the UUID pointing to /dev/sda3 and the > >> /dev/disk/by-id pointing to /dev/sda3? > > > > Please provide an example of such an UUID and the way you obtained it. > > Greetings Sven, > > So something odd has happened... > > # blkid |grep sda3 > /dev/sda3: PARTUUID="0003efe2-03" > /dev/mapper/sda3_crypt: UUID="f4aad427-3462-4dcf-a40d-617e90a7b1cb" > TYPE="swap" > > # grep sda3 /etc/crypttab > sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 > /dev/urandom cipher=aes-xts-plain64,size=256,swap > > That "PARTUUID" is odd because it used to be a UUID...huh...really not > sure what happened...but I have a guess (below)... > > But on my not-yet-updated-to-an-OS-with-systemd boxes they are either > configured for keys or use the UUID from blkid and that UUID is what is > in /etc/crypttab. In my first email this > "UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e" was taken from blkid. > Clearly that is no longer the case and would explain why UUID doesn't > work. :-) > > So off I went to read about UUID vs PARTUUID. Short notes: > UUID == filesystem > PARTUUID == partition > > Thus, I would want to point to the partition PARTUUID because (as you > pointed out to me earlier) the swap filesystem is going to change every > time due to urandom and thus the UUID should be changing on every > boot...blkid is probably seeing that this is a ever changing swap > partition and just returning the PARTUUID for me. > > But putting that PARTUUID in my /etc/crypttab didn't work and I ended up > with the systemd.fsck timing out and not mounting swap. Hrm. > > Well, I guess the disk-by-id works so I will just use that for now. ~Stack~, You can also use disk LABEL=. As implemented, the LABEL is actually applied to individual partition. As long as every partition has a different LABEL values there is no ambiguity. You only need to have unique values for partitions that you feel you will be mounting and umounting. Partitions with no LABEL value set never get compared by LABEL value. The system has always insisted on setting a unique UUID value on every partition. Its done that way because of a design decision of Debian developers. But it has a tiny flaw that you can avoid by using LABEL values, which YOU can be sure are unique because you didn't do repeats, whereas UUIDs are randomly generated and there is a tiny, but non-zero chance of repeats for UUIDs. > > Thanks again! I have learned a ton about cryptab, swap, UUID/PARTUUID, > and the boot process. :-) > > ~Stack~ ~Stack~, If I read your message above, you are having trouble understanding how to use the UUID/PARTUUID system for identifying partitions on disks. I suggest that you don't need to use it, and if you don't use it you don't need to understand it. It can be there because it has been put there during the initalization of Debian, and it won't hurt anything until you try to use it and make a mistake in trying to use it. I was once troubled by a similar situation when Debian first started to use UUID, until I realized that for some disks, I had no intention of ever changing the partion structure that was put there initially. For disks that I did have some special use and some ideas about how that special use might change in the future, I put LABEL=... on their partitions and used LABEL= paradigm to identify the partitions. This is what I do with all my external drives. And I put sticker on the outside of the drive enclosure with the LABEL= value written with a ball point pen on it. It is my personal responsibility to myself that I never put the same LABEL= value on two different disks. You can even put a LABEL= value on the root system disk that is always /dev/sda1 during installation. I suggest that you use LABEL=sda1. LABEL= settings can be any string of alphnumeric characters <= sixteen long. As I see it, the only benefit that you the user get from using the UUID/PARTUUID system is that if some Linux user is browsing through the internals of what is written on your disk, he may wonder where you got the software to do that and treat you with a little more respect. Let me assure you, you are not Rodney Dangerfield -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150401051932.ga31...@big.lan.gnu
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/29/2015 07:06 AM, Sven Hartge wrote: > ~Stack~ wrote: > >> One more question if you don't mind: I understand why the encrypted >> partition UUID is going to change every time, but the physical >> partition UUID for my /dev/sda3 shouldn't change though. If they are >> the same systemd.fsck shouldn't have a problem with the physical >> partition UUID of /dev/sda3, but yet it does (at least for me). So >> what is the difference between the UUID pointing to /dev/sda3 and the >> /dev/disk/by-id pointing to /dev/sda3? > > Please provide an example of such an UUID and the way you obtained it. Greetings Sven, So something odd has happened... # blkid |grep sda3 /dev/sda3: PARTUUID="0003efe2-03" /dev/mapper/sda3_crypt: UUID="f4aad427-3462-4dcf-a40d-617e90a7b1cb" TYPE="swap" # grep sda3 /etc/crypttab sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap That "PARTUUID" is odd because it used to be a UUID...huh...really not sure what happened...but I have a guess (below)... But on my not-yet-updated-to-an-OS-with-systemd boxes they are either configured for keys or use the UUID from blkid and that UUID is what is in /etc/crypttab. In my first email this "UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e" was taken from blkid. Clearly that is no longer the case and would explain why UUID doesn't work. :-) So off I went to read about UUID vs PARTUUID. Short notes: UUID == filesystem PARTUUID == partition Thus, I would want to point to the partition PARTUUID because (as you pointed out to me earlier) the swap filesystem is going to change every time due to urandom and thus the UUID should be changing on every boot...blkid is probably seeing that this is a ever changing swap partition and just returning the PARTUUID for me. But putting that PARTUUID in my /etc/crypttab didn't work and I ended up with the systemd.fsck timing out and not mounting swap. Hrm. Well, I guess the disk-by-id works so I will just use that for now. Thanks again! I have learned a ton about cryptab, swap, UUID/PARTUUID, and the boot process. :-) ~Stack~ signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
~Stack~ wrote: > One more question if you don't mind: I understand why the encrypted > partition UUID is going to change every time, but the physical > partition UUID for my /dev/sda3 shouldn't change though. If they are > the same systemd.fsck shouldn't have a problem with the physical > partition UUID of /dev/sda3, but yet it does (at least for me). So > what is the difference between the UUID pointing to /dev/sda3 and the > /dev/disk/by-id pointing to /dev/sda3? Please provide an example of such an UUID and the way you obtained it. S° -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5bgbenvjj...@mids.svenhartge.de
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/28/2015 06:45 PM, Sven Hartge wrote: > ~Stack~ wrote: > >> In another post on this thread you asked where I got that UUID from. >> That question fits in well here so I am just going to dump it all >> here. :-) > >> I just checked a number of my systems with blkid and the UUID's I am >> using are indeed the physical /dev/sdx# UUID's.. All of the bizarre >> behavior totally make sense in those layers you described if the LUKS >> swap UUID is auto generated and different every boot. > > If you use a static key and not /dev/urandom you can reuse the > swap-space that is already present. But that defeats the purpose of > encrypting the swap-space; you _want_ to forget the key and recreate the > encryption layer on every boot so that there is no chance of any > information leak from previous runs. > >> But at the same time, I am still not sure as to why systemd.fsck has >> issues with the UUID of the partition but is OK with the >> /dev/disk/by-id/pointer. > > UUID=... uses the UUID of the filesystem or swap-space on a partition, > _not_ the ID of the partition itself. That is totally different ID. > > Note that you have /dev/disk/by-id (which is the physical ID of the > device, partition, device map or md-RAID-set) while /dev/disk/by-uuid is > the UUID of whatever filesystem is on any device. > > You can only use the physical ones in /etc/crypttab. > > I guess by using the wrong (UU)ID the automatic dependency solvers of > systemd create a deadlock while trying to activate the correct units in > the correct order to do what you told it. This then turns into a fine > demonstration of computer sciences GIGO principle: Garbage In - Garbage Out. > > Of course, systemd could be a bit nicer and tell you if there is > something totally wrong, but maybe none of the authors has yet stumbled > upon this problem because they _know_ it does not work and hence never > tried it and never built any safe-guards into systemd to fail in a nicer > way. Thanks for the explanation. I now understand the results of a lot of my experiments today. It makes a lot more sense and I understand they garbage aspect of pointing to the swap file system (which changes) instead of the physical partition for swap. One more question if you don't mind: I understand why the encrypted partition UUID is going to change every time, but the physical partition UUID for my /dev/sda3 shouldn't change though. If they are the same systemd.fsck shouldn't have a problem with the physical partition UUID of /dev/sda3, but yet it does (at least for me). So what is the difference between the UUID pointing to /dev/sda3 and the /dev/disk/by-id pointing to /dev/sda3? Thanks Sven! You have been a great help in me understanding this better! signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
~Stack~ wrote: > In another post on this thread you asked where I got that UUID from. > That question fits in well here so I am just going to dump it all > here. :-) > I just checked a number of my systems with blkid and the UUID's I am > using are indeed the physical /dev/sdx# UUID's.. All of the bizarre > behavior totally make sense in those layers you described if the LUKS > swap UUID is auto generated and different every boot. If you use a static key and not /dev/urandom you can reuse the swap-space that is already present. But that defeats the purpose of encrypting the swap-space; you _want_ to forget the key and recreate the encryption layer on every boot so that there is no chance of any information leak from previous runs. > But at the same time, I am still not sure as to why systemd.fsck has > issues with the UUID of the partition but is OK with the > /dev/disk/by-id/pointer. UUID=... uses the UUID of the filesystem or swap-space on a partition, _not_ the ID of the partition itself. That is totally different ID. Note that you have /dev/disk/by-id (which is the physical ID of the device, partition, device map or md-RAID-set) while /dev/disk/by-uuid is the UUID of whatever filesystem is on any device. You can only use the physical ones in /etc/crypttab. I guess by using the wrong (UU)ID the automatic dependency solvers of systemd create a deadlock while trying to activate the correct units in the correct order to do what you told it. This then turns into a fine demonstration of computer sciences GIGO principle: Garbage In - Garbage Out. Of course, systemd could be a bit nicer and tell you if there is something totally wrong, but maybe none of the authors has yet stumbled upon this problem because they _know_ it does not work and hence never tried it and never built any safe-guards into systemd to fail in a nicer way. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4bga2r0jj...@mids.svenhartge.de
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/28/2015 03:37 PM, Sven Hartge wrote: > ~Stack~ wrote: [snip] >> In my /dev/disk/by-id/ directory I have both "dm-name-sda3_crypt" and >> "dm-uuid-CRYPT-PLAIN-sda3_crypt" which point to "../../dm-1". I can >> not use either of those in my /etc/crypttab because then I get the >> systemd.fsck problem again. > > Those device nodes only appear _after_ /etc/crypttab has been parsed. By > using them inside the crypttab, you create a chicken-and-egg problem. Oh. Then yeah, that does explain some things...quite a bit actually. >> Maybe that was the problem with the UUID?? > > I guess, you used the UUID of the swap inside the crypted device. But this > UUID changes on every boot, so it is of no use. Huh. More thoughts on that below. >> However, I also have "ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3" and >> "wwn-0x10001354922489237504x-part3" that point to "../../sda3". Both of >> those will boot correctly and mount swap. Here is my update that works: >> >> sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 >> /dev/urandom cipher=aes-xts-plain64,size=256,swap >> > > Of course. /etc/crypttab needs the device on which to create the crypted > device mapping. > >> So my guess, if I understand this correctly, is that if I use the >> encrypted container, systemd.fsck freaks out, tries to and fails to >> mount, then just ignores swap altogether. However, if I tell LUKS to >> encrypt the actual partition, that somehow means systemd.fsck is happy >> with it. So bizarre. > > No, not bizzare at all, quite logic if one thinks about what layer is > put on top of what other layer. > > You have /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 at the > bottom. On top of that, you get /dev/mapper/sda3_crypt. And on top of > that you get your swap-space. OK. So that actually does explain a lot. In another post on this thread you asked where I got that UUID from. That question fits in well here so I am just going to dump it all here. :-) I just checked a number of my systems with blkid and the UUID's I am using are indeed the physical /dev/sdx# UUID's.. All of the bizarre behavior totally make sense in those layers you described if the LUKS swap UUID is auto generated and different every boot. On the older Wheezy systems I also show a UUID for the LUKS swap device but I am not using that one. I rebooted a host and it did change. I have finally joined two previously disconnected thoughts in my brain and learned something today! :-) But at the same time, I am still not sure as to why systemd.fsck has issues with the UUID of the partition but is OK with the /dev/disk/by-id/pointer. Is this the correct way of doing it? (EG: have I been doing it wrong this whole time by using the physical partitions UUID? Should I update my other not-yet-updated-to-Jessie hosts to use /dev/disk/by-id?) Thanks for clarifying this! I do appreciate it. ~Stack~ signature.asc Description: OpenPGP digital signature
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
~Stack~ wrote: > On 03/28/2015 02:15 PM, David Wright wrote: Quoting ~Stack~ > (i.am.st...@gmail.com): >>> $ grep swap /etc/crypttab >>> # causes systemd to fsck swap >>> #sda3_crypt UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e /dev/urandom >>> cipher=aes-xts-plain64,size=256,swap >>> # systemd doesn't fsck swap >>> sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap >> >> That cure looks retrograde to me because it throws away the uniqueness >> of UUIDs. What if /dev/sda3 changes, for whatever reason. >> >> A systemd 216 man page for crypttab says: >>"WARNING: Using the swap option will destroy the contents of the >>named partition during every boot, so make sure the underlying >>block device is specified correctly." >> >> Could you not try using a /dev/disk/by-foo/... entry instead and see >> if that works? (I don't recognise the particular one Sven uses.) > OGood catch! That completely blitzed my mind. I knew there was a > reason for the UUID's! :-) > In my /dev/disk/by-id/ directory I have both "dm-name-sda3_crypt" and > "dm-uuid-CRYPT-PLAIN-sda3_crypt" which point to "../../dm-1". I can > not use either of those in my /etc/crypttab because then I get the > systemd.fsck problem again. Those device nodes only appear _after_ /etc/crypttab has been parsed. By using them inside the crypttab, you create a chicken-and-egg problem. > Maybe that was the problem with the UUID?? I guess, you used the UUID of the swap inside the crypted device. But this UUID changes on every boot, so it is of no use. > However, I also have "ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3" and > "wwn-0x10001354922489237504x-part3" that point to "../../sda3". Both of > those will boot correctly and mount swap. Here is my update that works: > > sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 > /dev/urandom cipher=aes-xts-plain64,size=256,swap > Of course. /etc/crypttab needs the device on which to create the crypted device mapping. > So my guess, if I understand this correctly, is that if I use the > encrypted container, systemd.fsck freaks out, tries to and fails to > mount, then just ignores swap altogether. However, if I tell LUKS to > encrypt the actual partition, that somehow means systemd.fsck is happy > with it. So bizarre. No, not bizzare at all, quite logic if one thinks about what layer is put on top of what other layer. You have /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 at the bottom. On top of that, you get /dev/mapper/sda3_crypt. And on top of that you get your swap-space. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3bg9o3djj...@mids.svenhartge.de
Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
On 03/28/2015 02:15 PM, David Wright wrote: > Quoting ~Stack~ (i.am.st...@gmail.com): [snip] >> $ grep swap /etc/crypttab >> # causes systemd to fsck swap >> #sda3_crypt UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e /dev/urandom >> cipher=aes-xts-plain64,size=256,swap >> # systemd doesn't fsck swap >> sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap > > That cure looks retrograde to me because it throws away the uniqueness > of UUIDs. What if /dev/sda3 changes, for whatever reason. > > A systemd 216 man page for crypttab says: >"WARNING: Using the swap option will destroy the contents of the >named partition during every boot, so make sure the underlying >block device is specified correctly." > > Could you not try using a /dev/disk/by-foo/... entry instead and see > if that works? (I don't recognise the particular one Sven uses.) OGood catch! That completely blitzed my mind. I knew there was a reason for the UUID's! :-) In my /dev/disk/by-id/ directory I have both "dm-name-sda3_crypt" and "dm-uuid-CRYPT-PLAIN-sda3_crypt" which point to "../../dm-1". I can not use either of those in my /etc/crypttab because then I get the systemd.fsck problem again. Maybe that was the problem with the UUID?? However, I also have "ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3" and "wwn-0x10001354922489237504x-part3" that point to "../../sda3". Both of those will boot correctly and mount swap. Here is my update that works: sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 /dev/urandom cipher=aes-xts-plain64,size=256,swap So my guess, if I understand this correctly, is that if I use the encrypted container, systemd.fsck freaks out, tries to and fails to mount, then just ignores swap altogether. However, if I tell LUKS to encrypt the actual partition, that somehow means systemd.fsck is happy with it. So bizarre. Thanks for pointing that out David! ~Stack~ signature.asc Description: OpenPGP digital signature
