Re: [gentoo-user] google SMTP with postfix - Password not accepted
On Sat, 14 Oct 2023 06:02:21 +0100, Peter Humphrey wrote: > On Tuesday, 20 June 2023 09:55:10 BST William Kenworthy wrote: > > getmail can facilitate getting googlemail into postfix. In my case, > > it fetches an mail then invokes sendemail to forward into postfix. > > The docs for the google side of the equation are quite good. > > Coming to this after a while, can you point me to the one that helps, > please? I've had a look round but I haven't found anything helpful. > Thanks. I use this getmail config for GMail. It uses procmail to deliver to Docecot, but it should work as a starting point for you. [retriever] type = SimpleIMAPSSLRetriever server = imap.gmail.com username = neil.bothw...@gmail.com password = thisisnotmyrealpassword mailboxes = ('Inbox',) [destination] type = MDA_external path = /usr/bin/procmail [options] verbose = 0 read_all = false delete = true -- Neil Bothwick Drink varnish and you'll have a lovely finish. pgpn587UHp8Y7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Getting output of a program running in background after a crash
On Friday, 13 October 2023 18:01:41 BST Dale wrote: > Michael wrote: > > On Friday, 13 October 2023 02:35:21 BST Dale wrote: > >> root@fireball / # cryptsetup benchmark > >> # Tests are approximate using memory only (no storage IO). > >> PBKDF2-sha1 878204 iterations per second for 256-bit key > >> PBKDF2-sha256 911805 iterations per second for 256-bit key > >> PBKDF2-sha512 698119 iterations per second for 256-bit key > >> PBKDF2-ripemd160 548418 iterations per second for 256-bit key > >> PBKDF2-whirlpool 299251 iterations per second for 256-bit key > >> argon2i 4 iterations, 1048576 memory, 4 parallel threads (CPUs) > >> for 256-bit key (requested 2000 ms time) > >> argon2id 4 iterations, 1048576 memory, 4 parallel threads (CPUs) > >> for 256-bit key (requested 2000 ms time) > >> # Algorithm | Key | Encryption | Decryption > >> > >> aes-cbc128b63.8 MiB/s51.4 MiB/s > >> > >> serpent-cbc128b90.9 MiB/s 307.6 MiB/s > >> twofish-cbc128b 200.4 MiB/s 218.4 MiB/s > >> > >> aes-cbc256b54.6 MiB/s37.5 MiB/s > >> > >> serpent-cbc256b90.4 MiB/s 302.6 MiB/s > >> twofish-cbc256b 198.2 MiB/s 216.7 MiB/s > >> > >> aes-xts256b68.0 MiB/s45.0 MiB/s > >> > >> serpent-xts256b 231.9 MiB/s 227.6 MiB/s > >> twofish-xts256b 191.8 MiB/s 163.1 MiB/s > >> > >> aes-xts512b42.4 MiB/s18.9 MiB/s > >> > >> serpent-xts512b 100.9 MiB/s 124.6 MiB/s > >> twofish-xts512b 154.8 MiB/s 173.3 MiB/s > >> > >> root@fireball / # > >> > >> > >> > >> root@nas:~# cryptsetup benchmark > >> # Tests are approximate using memory only (no storage IO). > >> PBKDF2-sha1 741567 iterations per second for 256-bit key > >> PBKDF2-sha256 910222 iterations per second for 256-bit key > >> PBKDF2-sha512 781353 iterations per second for 256-bit key > >> PBKDF2-ripemd160 547845 iterations per second for 256-bit key > >> PBKDF2-whirlpool 350929 iterations per second for 256-bit key > >> argon2i 4 iterations, 571787 memory, 4 parallel threads (CPUs) for > >> 256-bit key (requested 2000 ms time) > >> argon2id 4 iterations, 524288 memory, 4 parallel threads (CPUs) for > >> 256-bit key (requested 2000 ms time) > >> # Algorithm | Key | Encryption | Decryption > >> > >> aes-cbc128b 130.6 MiB/s 128.0 MiB/s > >> > >> serpent-cbc128b64.7 MiB/s 161.8 MiB/s > >> twofish-cbc128b 175.4 MiB/s 218.8 MiB/s > >> > >> aes-cbc256b 120.1 MiB/s 122.2 MiB/s > >> > >> serpent-cbc256b84.5 MiB/s 210.8 MiB/s > >> twofish-cbc256b 189.5 MiB/s 218.6 MiB/s > >> > >> aes-xts256b 167.0 MiB/s 162.1 MiB/s > >> > >> serpent-xts256b 173.9 MiB/s 204.5 MiB/s > >> twofish-xts256b 204.4 MiB/s 213.2 MiB/s > >> > >> aes-xts512b 127.9 MiB/s 122.9 MiB/s > >> > >> serpent-xts512b 201.5 MiB/s 204.7 MiB/s > >> twofish-xts512b 215.0 MiB/s 213.0 MiB/s > >> > >> root@nas:~# > >> > >> > >> > >> Is that about what you would expect? Fireball is on a 970 mobo. It's > >> slightly newer. I think the 770T is about 2 years older, maybe 3. > > > > grep AES /usr/src/linux/.config > > > > or, > > > > zgrep AES /proc/config.gz > > > > Or, grep your *current* kernel config wherever it is stored. > > I got the idea but assuming you wanted that info from the NAS box, I had > to dig a little. It's Ubuntu. It doesn't have kernel sources, no > config.gz in /proc either. I found this. I assume it is accurate. > Hopefully. > > > root@nas:~# cat /boot/config-5.15.0-86-generic | grep -i aes > CONFIG_SND_MAESTRO3=m > CONFIG_SND_MAESTRO3_INPUT=y > CONFIG_CRYPTO_AEGIS128_AESNI_SSE2=m > CONFIG_CRYPTO_AES=y > CONFIG_CRYPTO_AES_TI=m > CONFIG_CRYPTO_AES_NI_INTEL=m > CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m > CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m > CONFIG_CRYPTO_SM4_AESNI_AVX_X86_64=m > CONFIG_CRYPTO_SM4_AESNI_AVX2_X86_64=m > CONFIG_CRYPTO_DEV_PADLOCK_AES=m > CONFIG_CRYPTO_LIB_AES=y > root@nas:~# > > > I don't usually use modules. So, this is not something I run into > much. I'm adding this info since I think it will help as well. > > > root@nas:~# lsmod | grep -i aes > root@nas:~# The module is not loaded, hence the pedestrian performance. Check if the CPU has the AES instruction set - I expect it doesn't, or the module(s) would have been loaded: grep -m1 -o aes /proc/cpuinfo Ah! Just read your other message, the Phenom II
Re: [gentoo-user] google SMTP with postfix - Password not accepted
On Saturday, 14 October 2023 08:04:27 BST Neil Bothwick wrote: > I use this getmail config for GMail. It uses procmail to deliver to > Docecot, but it should work as a starting point for you. ---<8 Thanks for the help, Neil. Until now I've been using fetchmail, but I can't find any help in using it, and this entry in /etc/fetchmailrc fails with a permission error: poll pop.gmail.com proto pop3, user ".gmail.com", with password "", is "prh" here, ssl, dropdelivered, fetchall, no keep; I also tried setting up a gmail IMAP source in KMail, and that worked so I assume the permissions are right at their end. (I removed the account when KMail kept resurrecting scores of mails I'd already deleted, even though access on my mobile showed an absence of mails.) Perhaps I should switch to getmail... -- Regards, Peter.
Re: [gentoo-user] Getting output of a program running in background after a crash
On Saturday, 14 October 2023 04:21:23 BST Dale wrote: > Frank Steinmetzger wrote: > > Am Thu, Oct 12, 2023 at 08:35:21PM -0500 schrieb Dale: > >> Frank Steinmetzger wrote: > >>> Am Thu, Oct 12, 2023 at 10:44:39PM +0100 schrieb Michael: > Why don't you test throughput without encryption to confirm your > assumption?>>> > >>> What does `cryptsetup benchmark` say? I used to use a Celeron G1840 in > >>> my > >>> NAS, which is Intel Haswell without AES_NI. It was able to do ~ 150 MB/s > >>> raw encryption throughput when transferring to or from a LUKS’ed image > >>> in a ramdisk, so almost 150 % of gigabit ethernet speed. > >> > >> […] > >> I've never used that benchmark. Didn't know it exists. This is the > >> results. Keep in mind, fireball is my main rig. The FX-8350 thingy. > >> The NAS is currently the old 770T system. Sometimes it is a old Dell > >> Inspiron but not this time. ;-) > >> > >> root@fireball / # cryptsetup benchmark > >> […] > >> # Algorithm | Key | Encryption | Decryption > >> aes-cbc128b63.8 MiB/s51.4 MiB/s > >> serpent-cbc128b90.9 MiB/s 307.6 MiB/s > >> twofish-cbc128b 200.4 MiB/s 218.4 MiB/s > >> aes-cbc256b54.6 MiB/s37.5 MiB/s > >> serpent-cbc256b90.4 MiB/s 302.6 MiB/s > >> twofish-cbc256b 198.2 MiB/s 216.7 MiB/s > >> aes-xts256b68.0 MiB/s45.0 MiB/s > >> serpent-xts256b 231.9 MiB/s 227.6 MiB/s > >> twofish-xts256b 191.8 MiB/s 163.1 MiB/s > >> aes-xts512b42.4 MiB/s18.9 MiB/s > >> serpent-xts512b 100.9 MiB/s 124.6 MiB/s > >> twofish-xts512b 154.8 MiB/s 173.3 MiB/s > >> root@fireball / # > > > > Phew, this looks vry slow. As you can clearly see, this is not enough > > to even saturate Gbit ethernet. Unfortunately, I don’t have any benchmark > > data left over from the mentioned celeron. > > (Perhaps that’s why the industry chose to implement AES in hardware, > > because it was the slowest of the bunch.) > > > > It looks like there is no hardware acceleration involved. But according to > > https://en.wikipedia.org/wiki/List_of_AMD_FX_processors#Piledriver-based > > and https://www.cpu-world.com/CPUs/Bulldozer/AMD-FX-Series%20FX-8350.html > > it has the extension. I’d say something is amiss in your kernel. Yes, I also think AES_NI has not been enabled in Dale's kernel config. I just ran 'cryptsetup benchmark' on an A10-7850K APU (Kaveri Steamroller core as opposed to the 2 year older FX-8350 Vishera Piledriver core) and aes-xts fares much better; # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 1028015 iterations per second for 256-bit key PBKDF2-sha2561464491 iterations per second for 256-bit key PBKDF2-sha5121123875 iterations per second for 256-bit key PBKDF2-ripemd160 708497 iterations per second for 256-bit key PBKDF2-whirlpool 389515 iterations per second for 256-bit key argon2i 5 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256- bit key (requested 2000 ms time) argon2id 5 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256- bit key (requested 2000 ms time) # Algorithm | Key | Encryption | Decryption aes-cbc128b 586.6 MiB/s 2169.8 MiB/s serpent-cbc128b88.6 MiB/s 330.6 MiB/s twofish-cbc128b 203.1 MiB/s 277.6 MiB/s aes-cbc256b 443.0 MiB/s 1712.5 MiB/s serpent-cbc256b89.7 MiB/s 329.8 MiB/s twofish-cbc256b 204.0 MiB/s 277.3 MiB/s aes-xts256b 1840.9 MiB/s 1857.6 MiB/s <== serpent-xts256b 288.4 MiB/s 299.6 MiB/s twofish-xts256b 240.6 MiB/s 252.9 MiB/s aes-xts512b 1459.3 MiB/s 1474.2 MiB/s <== serpent-xts512b 291.6 MiB/s 299.0 MiB/s twofish-xts512b 242.8 MiB/s 252.7 MiB/s Whether 256 or 512 bit aes-xts performance would fill up a 1Gbps pipe. Without AES_NI the performance on this CPU is ~10 times slower. I expect the FX-8350 would produce comparable results once the kernel crypto options are sorted. > >>> Ah right, you use NFS. If not, I’d have suggested not to use rsync over > >>> ssh, because that would indeed introduce a lot of encryption overhead. > >> > >> I thought nfs was the proper way. I use ssh and I use rsync, > >> separately. Didn't know they can be used together tho. > > > > When you do `rsync -ai source host:/path/to/destination/`, you use ssh for > > transport. > > Well, I may be doing this all wrong. First, I ssh into the NAS box. I > do the decrypt stuff and mount the LV in it's proper place. Then I > swit
Re: [gentoo-user] google SMTP with postfix - Password not accepted
On Saturday, 14 October 2023 12:26:29 BST I wrote: > Perhaps I should switch to getmail... On the other hand, I'd prefer to stick with fetchmail for my Zen POP3 account, since it's working well. Then I could use getmail to fetch my gmail mail. Would that be safe? If it works I could move Zen mail to getmail later, at my leisure. (That's the only sort of time I have these days... :( ) -- Regards, Peter.
Re: [gentoo-user] Getting output of a program running in background after a crash
Mark Knecht wrote: > > > I'm planning on my new rig having the Ryzen 5900X. Is the 5950 > better? While I've kinda picked that one, I'm open to ideas if it is > faster and I can afford it. As it is, I'm looking at between $300 and > $350 for the 5900. My last CPU cost a little over $100. > > > > I'm not going to say one is better than the other. The 5950X has more > cores, the 5900X runs at a higher speed. It depends on your workload > which will be better for you. I do a lot of things based around > machine learning where I felt I was better off having more cores - > give 12 to the ML job, keep 4 for my personal use. It's worked out > well. However you don't ever talk much about what you actually use > your computers for other than having 250 disk drives and moving data > around your network. Depending on how you are moving data you might be > better off with 5900X going faster. > > You can use this site to get some comparative data: > > https://cpu.userbenchmark.com/Compare/AMD-Ryzen-9-5950X-vs-AMD-Ryzen-9-5900X/4086vs4087 > > BTW - you probably know both of these CPUs have been superseded by the > 7900X and 7950X. THere's also the 3D versions which have faster and > larger cache. > > > While at it. In the past, I always bought the mobo, CPU and memory > from the same place. Generally if one of those is bad, it's sometimes > hard to know which one is bad. Sometimes even the BIOS beep codes are > no help because there may be none. If the mobo doesn't boot up, worst > case, send all three back to the same place. Given how far things > have come, do I need to worry about a bad one out of the box anymore? > I can save some money if I buy from different places. > > Cannot answer but you need a return policy from every vendor. If it > doesn't boot and you cannot figure it out you send everything back to > multiple vendors I guess. > > Until recently I built all my machines myself. My 5900X machine has > water cooling and I had cash so I paid a local storefront here to > build it. I bought right in the middle of the pandemic and the chip > shortage cost me huge dollars. Most expensive machine I've ever owned. > Probably could build it today for less than 50% of what I paid. Now that you mention that, there isn't much difference in price between the two, depending on who I buy from. There are some good deals for used but I'm kinda leery about used. You never know if they overclocked it and ran it to hot or something and it shorten its life. One thing tho, different CPU socket, different mobo is needed. Gotta start my research over again. ;-) Hardest thing is finding mobo with several PCIe slots. They have cut way back on those. Dale :-) :-)
Re: [gentoo-user] google SMTP with postfix - Password not accepted
On Sat, 14 Oct 2023 14:28:53 +0100, Peter Humphrey wrote: > On the other hand, I'd prefer to stick with fetchmail for my Zen POP3 > account, since it's working well. Then I could use getmail to fetch my > gmail mail. Would that be safe? > > If it works I could move Zen mail to getmail later, at my leisure. > (That's the only sort of time I have these days... :( ) Here's my getmail config for Zen [retriever] type = SimplePOP3Retriever server = mailhost.zen.co.uk username = zen123456 password = yeahyeahyeah [destination] type = MDA_external path = /usr/bin/procmail [options] verbose = 0 read_all = false -- Neil Bothwick You do not need a parachute to skydive. You only need a parachute to skydive twice. pgpAw6u2sYpM6.pgp Description: OpenPGP digital signature
Re: [gentoo-user] google SMTP with postfix - Password not accepted
On 14/10/23 21:28, Peter Humphrey wrote: On Saturday, 14 October 2023 12:26:29 BST I wrote: Perhaps I should switch to getmail... On the other hand, I'd prefer to stick with fetchmail for my Zen POP3 account, since it's working well. Then I could use getmail to fetch my gmail mail. Would that be safe? If it works I could move Zen mail to getmail later, at my leisure. (That's the only sort of time I have these days... :( ) getmail works fine with gmail - just follow their instructions to configure. getmail itself is a bit flakey - using it with hydroxide as a proton bridge it keeps going to sleep(need to restart getmail every hour), and on 3 accounts with my ISP I get random crashes with no indication why. But with gmail and ventraip.mail its quite stable. On the plus side imap getmail IDLE works ... I had problems with fetchmail so moved to getmail. BillK
[gentoo-user] Cronie update breaks anacron
The latest update to cronie (sys-process/cronie-1.7.0) seems to have broken anacron functionality. The file /etc/cron.hourly/0anacron tries to source the file /etc/default/anacron, which does not exist. The full error message looks like this: /etc/cron.hourly/0anacron: line 11: /etc/default/anacron: No such file or directory run-parts: /etc/cron.hourly/0anacron exited with return code 1 Of course I could just create an empty file, and it would work again, but I am wondering if there is something broken in the default setup, which was forgotten to bundle in the cronie install package? Anybody else experiencing this? Did I miss something?