Re: [gentoo-user] Root on NFS Suspend/Resume support
On 12/10/18 8:03 PM, Tsukasa Mcp_Reznor wrote: Has anyone managed to get suspend/resume to work on diskless machines using NFS as the root? ~blink~ I haven't tried to suspend / resume diskless machines. (I've not done much with diskless machines, but it's on my to do list.) But I don't think I would have thought about trying to suspend / resume a diskless machine. Are we talking about a wired Ethernet network connection with static IP(s)? Or something more complex? Aside: I'm wondering why a diskless machine is using suspend / resume. If you're bored, I'd like to have my (apparently limited) world view expanded. Suspend works like normal, but resume hard locks, can't seem to get any error's or anything as it's not sending to any log files naturally. Have you tried using any network based logging? Can syslog log to a network block device? Doesn't the kernel have some network logging? Or the ability to log debug info somewhere other than a file? I have 3 machines currently running this setup, just trying to save some power. If it helps they are all using Realtek NICs. Okay. I conceptually get saving power. How are you waking them up? User interaction? Clock? Magic packet? My google-fu hasn't turned up anything in the last 5 years. So, you've been working on it for a while. Are any of your problems related to stale file handles? I.e. the diskless NFS client disagreeing with the NFS server about the state of the files? Is the NFS server closing the files after a timeout? Thanks You're welcome. But I'm not sure I helped. I would like to learn what you figure out.
[gentoo-user] Root on NFS Suspend/Resume support
Has anyone managed to get suspend/resume to work on diskless machines using NFS as the root? Suspend works like normal, but resume hard locks, can't seem to get any error's or anything as it's not sending to any log files naturally. I have 3 machines currently running this setup, just trying to save some power. If it helps they are all using Realtek NICs. My google-fu hasn't turned up anything in the last 5 years. Thanks
Re: [gentoo-user] Re: CPU upgrade and LVM questions.
On 12/10/2018 05:54 PM, Dale wrote: > Neil Bothwick wrote: >> On Mon, 10 Dec 2018 16:33:10 -0500, taii...@gmx.com wrote: >> Not sure which country would be a reliable location though, I wouldn't trust Western European countries either. >>> USA is currently the best option since there have never been proven >>> backdoors in made in usa hardware but plenty in chinese made hardware >>> such as the recent motherboard hack chip scandal. >> So that proves that US manufacturers are better at hiding their back >> doors? >> >> Or is it a numbers game, there are a hell of a lot more systems made in >> China, so the chances of a backdoor being discovered is higher. >> >> Either way, lack of evidence of insecurity is not proof of security. >> So tell us what is your perfect country for hardware manufacturing? Name one other country on earth besides america where you can say no to a governmental request for a backdoor in your hardware or software products and not end up in prison. In the mean time will you continue to buy chinese products with proven backdoors since getting that is somehow better than something that is only almost perfect? The amd bulldozer and piledriver CPU's like the FX-8350 and its opteron counterparts are made in germany (the packaging is done in china but at that point afaik there isn't much that can be done to fuck with it) but that still wouldn't satisfy you since germany doesn't have anything like the constitution - they have no freedom of speech. The future of freedom computing is OpenPOWER and RISC-V since they are the only owner controlled archs that have real performance and features, in other words they have juice.
Re: [gentoo-user] Re: CPU upgrade and LVM questions.
Neil Bothwick wrote: > On Mon, 10 Dec 2018 16:33:10 -0500, taii...@gmx.com wrote: > >>> Not sure which country would be a reliable location though, I >>> wouldn't trust Western European countries either. >> USA is currently the best option since there have never been proven >> backdoors in made in usa hardware but plenty in chinese made hardware >> such as the recent motherboard hack chip scandal. > So that proves that US manufacturers are better at hiding their back > doors? > > Or is it a numbers game, there are a hell of a lot more systems made in > China, so the chances of a backdoor being discovered is higher. > > Either way, lack of evidence of insecurity is not proof of security. > > I think the best thing to do, trust none of them until proven secure. Let people test them, try to hack into them and do other things to see if there is a backdoor or not. The same with encryption. One can say it is secure but until it is tested very hard for a significant amount of time, one never knows if it is or not. Some security problems/holes don't show up for years. Dale :-) :-)
Re: [gentoo-user] Re: CPU upgrade and LVM questions.
On Mon, 10 Dec 2018 16:33:10 -0500, taii...@gmx.com wrote: > > Not sure which country would be a reliable location though, I > > wouldn't trust Western European countries either. > > USA is currently the best option since there have never been proven > backdoors in made in usa hardware but plenty in chinese made hardware > such as the recent motherboard hack chip scandal. So that proves that US manufacturers are better at hiding their back doors? Or is it a numbers game, there are a hell of a lot more systems made in China, so the chances of a backdoor being discovered is higher. Either way, lack of evidence of insecurity is not proof of security. -- Neil Bothwick Secret hacker rule #11: hackers read manuals. pgpYa8OKzVwWS.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Encryption questions
On Mon, 10 Dec 2018 09:21:38 -0700, Grant Taylor wrote: > > It sounds like ecryptfs would suit your needs best. As it works on > > directories, you don't need separate mount points for each encrypted > > directory. > > The last time I looked at eCryptFS it /did/ need mount points for > accessing the unencrypted contents. But you don't need to dedicate an > entire file system to the encryption. Sorry, poor choice of words. I really meant separate filesystems. Of course each mounted ecrypts directory needs a mount point! -- Neil Bothwick deja vous - the act of forgetting someone's name /again/ despite being introduced to them several times. pgpcgTlO613TJ.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: CPU upgrade and LVM questions.
On 12/09/2018 01:57 PM, J. Roeleveld wrote: > On December 9, 2018 6:23:07 PM UTC, "taii...@gmx.com" wrote: >> On 12/07/2018 06:47 PM, Nikos Chantziaras wrote: >>> On 07/12/2018 09:30, Dale wrote: Nikos Chantziaras wrote: > If you want to see all of the installed packages that are affected, > you need to set CPU_FLAGS_X86 to an empty string: > > CPU_FLAGS_X86="" > > and then do "emerge -puDN --with-bdeps=y @world". This is because > CPU_FLAGS_X86 is not empty by default. It contains sse and sse2 by > default, because these are supported by all 64-bit CPUs. > What I did, I commented out the whole line and ran it that way. >>> >>> If you comment it out, it will have default values. If you set it to >> an >>> empty string, you should be able to see which packages make use of >> the >>> default flags (like sse and sse2.) >>> >>> Note it's a pretend emerge (-p). Just to check which packages you >> have >>> installed that make use of these flags. >>> >>> One last question for anyone who has done this recently. When >> finished, I'll have a FX-8350 CPU with 8 cores at 4.0/4.2GHz, 32GBs of memory >> all on a Gigabyte 970 series mobo. Would there be any point in >> upgrading to a whole new rig or is what I have about as fast is reasonable to >> build? I don't do gaming or anything. Even the GTX 650 video card is >> likely overkill for what I do here. The older 200 series card is working >> just fine. On one hand, my current build is several years old. On the other, computers seem to have reached their peak. I'm sure there is more powerful systems out there but would I be any better off with >> one? >> >> Since the AM3+ and its C32/G34 Opteron counterparts are the last and >> best x86 cpus without ME/PSP I would say you are better off with what >> you have - the best piledriver cpus like the FX-8350+ are still able to >> play the latest games and in a VM via IOMMU-GFX if you want. >> >> In any case I would consider a OpenPOWER (ppc64/ppc64le) arch system >> (like the blackbird or talos 2) as an upgrade path instead of any >> futher >> x86 stuff as there aren't any black boxes, there is >> documentation+firmware sources and the cpus are made in usa. > > Made in USA isn't necessarily a good thing when talking about not wanting any > hidden back doors. Hell of a lot better than buying black box hardware from china. x86 is definitely backdoored due to the ME/PSP and various other DRM features that mean you no longer own your x86 computer. In the US you aren't going to prison for telling the government you won't put a backdoor in your hardware whereas in china and many others you would go to jail without even a trial even in western europe people are jailed for saying the wrong things on the internet. It is currently the hardest place for an authority figure to lean on you. Since the only users of POWER are fortune 500's and the government itself it needs to be secure and not fucked around with, ironically the chinese government is buying OpenPOWER now as they want a secure, owner controlled, highly documented and non-x86 high performance CPU (there is absolutely no hardware code signing not even for the cpu microcode and no blobs are required for hardware initiation unlike with new x86 stuff) One doesn't have to put an actual func_backdoor backdoor in a CPU since something so complex will have exploitable bugs that even the manufacturer doesn't know about such as the (fixed via microcode) 2014 AMD Piledriver NMI to root exploit where you could get root and SMM access from a tiny userspace script and that was in there for years without anyone noticing. > Not sure which country would be a reliable location though, I wouldn't trust > Western European countries either. USA is currently the best option since there have never been proven backdoors in made in usa hardware but plenty in chinese made hardware such as the recent motherboard hack chip scandal.
[gentoo-user] Can't "emaint sync -A" successfully
Hi guys. For some days now (can't say how many) I have been unable to get "emaint sync -A". At the end, it says something like this: sent 116.30K bytes received 23.70M bytes 266.06K bytes/sec total size is 218.86M speedup is 9.19 * Manifest timestamp: 2018-12-10 18:38:44 UTC * Valid OpenPGP signature found: * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 * - timestamp: 2018-12-10 18:38:44 UTC * Verifying /usr/portage/.tmp-unverified-download-quarantine ...!!! Manifest verification failed: Manifest mismatch for metadata/md5-cache/media-gfx/pdf2svg-0.2.3 BLAKE2B: expected: 10d29df75f139b4c2c0335a2fc179b656fddba63ce5eb744a357601e22ba8691d03837845e39c8a080657fa22e533321476ab66205cbd5318ec1cd9d7492fdd2, have: 98555069f2ba50b4820c4a86525e1c8a2d8789de76b7cc0ba353f8edafd8df28d02585bb175b010d234b9ce055ecfd977a824ed8a55036923e79396bb9eeaa5d SHA512: expected: 2f4c6dd0052d813dfd07620bd4222d840784b76b066ca4e4ec87e9fd4d0be329060a143f1392cc8a6925126f65d2ffccef92e873a734b61565fedd949a7ee353, have: a46ef274a60bce0ee5a08022f85c769121fe6dc7c83560c5a57a09cf74a2cbd29bd8fd41602ffba2b72ea473800a9e5fff57dc104931b0d773a3003b9a2500c0 q: Updating ebuild cache in /usr/portage ... q: Finished 35801 entries in 0.098986 seconds Action: sync for repo: gentoo, returned code = 1 The manifest mismatch, for a few days, has been "pdf2svg", but it has changed from a few days ago, it was another manifest mentioned at the error message. So, I have had to update using /usr/bin/emerge-webrsync . That's not big deal, but I really would like to understand a bit more, like, am I doing something wrong? Thank you! Francisco
Re: [gentoo-user] Encryption questions
On 12/10/2018 02:25 AM, Neil Bothwick wrote: It sounds like ecryptfs would suit your needs best. As it works on directories, you don't need separate mount points for each encrypted directory. The last time I looked at eCryptFS it /did/ need mount points for accessing the unencrypted contents. But you don't need to dedicate an entire file system to the encryption. I.e. /home/user/.precious is mounted on /home/user/precious So /home/user/precious is a mount point, but is not backed by an independent file system per say. Contents in /home/user/precious will be clear text while the contents of /home/user/.precious will be encrypted. -- Grant. . . . unix || die
Re: [gentoo-user] CPU upgrade and LVM questions.
Neil Bothwick wrote: > On Sun, 9 Dec 2018 20:38:25 -0600, Dale wrote: > >>> Is there an aspect of it that doesn't make sense? Or that you're >>> uncomfortable with? Can I help alleviate the worry? >> Just making sense of it. Trying to get it firmly in my mind. It just >> seems to simple and easy to move that much data around and swap drives >> even while in use. o-O > But the whole point of LVM is to make it easy to do things like that. If > this task were more difficult it would be a massive fail for LVM. > > This is true but this is *ME*. ROFL Nothing should be *that* easy. lol BTW, my drive and CPU fan is coming in today. Let's see if I feel like I have enough energy to mess with it today. May do CPU first. I can do a new set of backups while recompiling with new settings for new CPU too. I also finished my -e world this AM with only one failure. Dang, emerge is getting good. ;-) I wonder what today will bring. Dale :-) :-)
Re: [gentoo-user] Encryption questions
On Monday, 10 December 2018 09:25:58 GMT Neil Bothwick wrote: > On Sun, 9 Dec 2018 23:15:21 -0600, Dale wrote: > > Well, I thought it may be simpler. Since I've never tried encryption > > before, I don't know first hand how it works or what it takes to use the > > files. I've read where people password protect their mobo, bootloader > > and their entire storage system. Basically, without the proper > > passwords, you can't boot the system or access it from another system > > either. That is overkill for me for sure. If anything, I'm on the > > other end of the scale. I just want a directory, which could be a mount > > point, that is encrypted. Knowing what tool is best may help be figure > > out whether it is a mount point, a regular directory or what. I've read > > where some whole file systems can be encrypted or it can be done on a > > directory level. I'm not sure what works the best tho. > > It sounds like ecryptfs would suit your needs best. As it works on > directories, you don't need separate mount points for each encrypted > directory. ISTR there is a PAM module to unlock your ecryptfs directories > when you log into your desktop (it needs a password login not > auto-login). > > As already mentioned you can backup the encrypted files so your backups > are automatically secure. One point about ecryptfs is increases the size > of each file by a fixed amount. This doesn't matter with larger files but > if you have a directory full of smaller files, like a mail client cache, > there may be a noticeable increase in disk usage. > > Encrypting the whole filesystem may be more convenient as it means you > don't have to worry about what is encrypted and what is not, but you > would need to back up to an encrypted drive. > > Neither method will protect you from remote access while you are logged > in as the encrypted files will be unlocked. Another thing to mention is filesystem encryption. I don't know if ext4 encryption is mature enough for production implementations, but this was added to the kernel a few years now. sys-fs/e2fsprogs includes e4crypt which can be used to encrypt directories and files, each one secured with a different encryption key, and each encryption key protected (encrypted) with a master key in your keyring. So even if one file's encryption key is cracked, the rest of the encrypted files should be secure. BTW, if we're talking about a few files which are not being accessed frequently, it may be worth considering the use of symmetric encryption using a passphrase (gpg, or openssl). This would require no additional configuration, overlay fs, keyrings, etc., thus making it simpler to use and transport. However, the file names themselves won't be encrypted using this method, which may or may not be important depending on your use case. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] CPU upgrade and LVM questions.
On Sun, 9 Dec 2018 20:38:25 -0600, Dale wrote: > > Is there an aspect of it that doesn't make sense? Or that you're > > uncomfortable with? Can I help alleviate the worry? > > Just making sense of it. Trying to get it firmly in my mind. It just > seems to simple and easy to move that much data around and swap drives > even while in use. o-O But the whole point of LVM is to make it easy to do things like that. If this task were more difficult it would be a massive fail for LVM. -- Neil Bothwick WinErr 678: This will end your Windows session. Do you want to play another game? pgphSS_vHFOsp.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Encryption questions
On Sun, 9 Dec 2018 23:15:21 -0600, Dale wrote: > Well, I thought it may be simpler. Since I've never tried encryption > before, I don't know first hand how it works or what it takes to use the > files. I've read where people password protect their mobo, bootloader > and their entire storage system. Basically, without the proper > passwords, you can't boot the system or access it from another system > either. That is overkill for me for sure. If anything, I'm on the > other end of the scale. I just want a directory, which could be a mount > point, that is encrypted. Knowing what tool is best may help be figure > out whether it is a mount point, a regular directory or what. I've read > where some whole file systems can be encrypted or it can be done on a > directory level. I'm not sure what works the best tho. It sounds like ecryptfs would suit your needs best. As it works on directories, you don't need separate mount points for each encrypted directory. ISTR there is a PAM module to unlock your ecryptfs directories when you log into your desktop (it needs a password login not auto-login). As already mentioned you can backup the encrypted files so your backups are automatically secure. One point about ecryptfs is increases the size of each file by a fixed amount. This doesn't matter with larger files but if you have a directory full of smaller files, like a mail client cache, there may be a noticeable increase in disk usage. Encrypting the whole filesystem may be more convenient as it means you don't have to worry about what is encrypted and what is not, but you would need to back up to an encrypted drive. Neither method will protect you from remote access while you are logged in as the encrypted files will be unlocked. -- Neil Bothwick If a man is standing in the middle of the forest speaking and there is no woman around to hear him - Is he still wrong? pgpm7OUdUYKbP.pgp Description: OpenPGP digital signature
