Gentoo msmtp and local mail

I have installed msmtp to handle mail I send from mutt using my accounts. But, I would like to get mail from local users, such as cron-jobs and smartmontools as well.
I have researched it, and have found that Gentoo blocks use of more than one Mail Transfer Agent (MTA). This, I found from this forum answer
msmtp is counted as an MTA, and thus, I cannot install sendmail or exim, which my Debian system uses.
So, my alternatives seem to be to either

  1. configure the msmtp sendmail symlink to use one account by default, and use a sane “from” address.
  2. Manually install msmtp after emerging another MTA.

The drawback with 1. is that I will get cron mail to one of my accounts, rather than having it local to the computer. And I need to be careful when setting it up, so that I don’t run into the problem in this question.

The drawback with 2. is that it is more of a hack to enable use of two MTAs. I wonder why Gentoo forbids use of two MTAs while Debian accepts it.

To be continued

Gentoo ZFS

So, background: I wanted to try out a BSD, specifically TrueOS (link).
I installed it and chose the bsd-bootloader. This was a bad choice, though, because that didn’t work on my GPT partitioned EFI-boot hard drive.
I figured, I could try to boot it with grub, but, my manual configuration tests didn’t work out, so maybe I should try to make grub detect it automatically. For this, the file system needs to be able to be read, and it is using ZFS; thus, I need to be able to read ZFS in gentoo. I found this.

During the install, I got the error that CONFIG_ZLIB_DEFLATE was not set in the kernel. I searched and found this thread. From it, I figured out, I should enable the option
Cryptographic API ---->
Deflate compression algorithm

as a module.
Now, I could emerge zfs and modprobe zfs

Gentoo – connect android device with jmtpfs

I have an android device, that I transfer files to and from with jmtpfs in my Debian system.
I searched and found the package sys-fs/jmtpfs, which I unmasked and emerged.
When the installation has finished it complained:* CONFIG_FUSE_FS: is not set when it should be. so I figured, that is probably a Kernel configuration I have not made.
I found it here:
File systems --->
FUSE (Filesystem in Userspace) support

I enabled it as a module.
Now I could modprobe fuse, and then run tmtpfs /path/to/mount/it

Gentoo – enabling sound

So, I installed vlc, only to find I had no sound. So I looked in the hand book configuring ALSA.
I had the sound device:
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
I changed the kernel configuration and added
Device Drivers --->
<*> Sound card support
<*> Advanced Linux Sound Architecture --->
[*] PCI sound devices --->
Intel/SiS/nVidia/AMD/ALi AC97 Controller
Intel/SiS/nVidia/AMD MC97 Modem

as modules.
And I added the following into the kernel:
Device Drivers --->
<*> Sound card support
<*> Advanced Linux Sound Architecture --->
[*] PCI sound devices --->
Select the driver for your audio controller, e.g.:
<*> Intel HD Audio ---> (snd-hda-intel)
-*- Allow dynamic codec reconfiguration
[*] Support digital beep via input layer
(1) Digital beep registration mode (0=off, 1=on)
[*] Support initialization patch loading for HD-audio
<*> Build Realtek HD-audio codec support
...
<*> Build HDMI/DisplayPort HD-audio codec support
...
-*- Enable generic HD-audio codec parser

Then, I followed the guide, and rebooted. Now I have sound.

Ssh login fails with debug1: SSH2_MSG_KEXINIT sent\n Connection closed by XX

I was playing around with my apache settings yesterday, and decided to ditch what I had and checkout what was in master in etckeeper with etckeeper vcs checkout HEAD.
After that, I couldn’t log in to my server again with ssh:
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
Connection closed by IP-ADDRESS

I thought it was strange.
After getting the logwatch mail, I got these error messages in the log:
error: key_load_private: bad permissions : 58 time(s)
error: Could not load host key: /etc/ssh/ssh_host_rsa_key : 29 time(s)
error: Permissions 0644 for '/etc/ssh/ssh_host_dsa_key' are too open. : 29 time(s)
error: It is recommended that your private key files are NOT accessible by others. : 58 time(s)
error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ : 116 time(s)
fatal: No supported key exchange algorithms [preauth] : 29 time(s)
error: This private key will be ignored. : 58 time(s)
error: Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open. : 29 time(s)
error: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ : 58 time(s)
error: Could not load host key: /etc/ssh/ssh_host_dsa_key : 29 time(s)

So, something had changed the permissions to /etc/ssh/ssh_host_dsa_key. First I though: “Damn, have I been rooted now? That is just fair with my previous bad password policy”.
Then I gave it more thought, and remembered my restoring with etckeeper. I searched and found this question.
Looks like you need to run etckeeper init after checking out.
The problem now, because the server is far away from me, is to get somebody technical to connect a screen and keyboard to the computer and follow my instructions.
EDIT: etckeeper init was not enough. It didn’t restore the file permissions. I wonder how many other files have wrecked file permissions now :/

Gentoo – searching mail with notmuch

When setting up notmuch for use with mutt in Debian, I followed this guide
The macro setup there, didn’t work in the Gentoo installation, though.
I looked here and used the macro there:
macro index "unset wait_key\
read -p 'notmuch query: ' x; echo \$x >~/.cache/mutt_terms\ ~i \"\`notmuch search --output=messages \$(cat ~/.cache/mutt_terms)\
| head -n 600 | perl -le '@a=<>;chomp@a;s/\^id:// for@a;$,=\"|\";print@a'\`\"" \
"show only messages matching a notmuch pattern"

Removing a web page from a server, but browser still displays it

I was playing around with with sites-enabled in apache, and removed an old web page (removing the file), but my browser would still display that page, even though I had removed it. It appeared that the browser cached that page. I opened the site in another web browser, and there, it displayed correctly.
Solution: I found out, you can open a new private window in firefox, and then, it will not show an old cached site.

Gentoo – mutt with sidebar (sidebar not showing)

I found, you need to enable the sidebar use flag, so I created the file /etc/portage/package.use/mutt with the contents:mail-client/mutt sidebar.
Still, no sidebar was displayed. Then, I found out, you need to set the width of sidebar in .muttrc, otherwise, it will probably have the width 0. So I set the width with the line set sidebar_width=20

A noobs guide to installing Gentoo on a core i5 2500K – cryptsetup

So, I use cryptsetup to encrypt a drive I have, so I would really like to continue using cryptsetup.
It is easy to emerge cryptsetup with emerge --ask sys-fs/cryptsetup.
Then, trying to run it, for example cryptsetup benchmark, I got the error:
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.

I searched and found this thread. I extracted the parts I needed for it to work for me:
The following kernel configuration options needed to be enabled:
(If I recall correctly)
CONFIG_CRYPTO_XTS
CONFIG_CRYPTO_AES_X86_64
CONFIG_CRYPTO_AES_NI_INTEL

The first two are for my encryption algorithm xts-plain64. The Intel option is because I have an Intel CPU.
Still no go, I found I had to enable some hashes as well (logically):
CONFIG_CRYPTO_SHA1
CONFIG_CRYPTO_SHA1_SSSE3
CONFIG_CRYPTO_SHA256_SSSE3
CONFIG_CRYPTO_SHA512_SSSE3
CONFIG_CRYPTO_SHA1_MB
CONFIG_CRYPTO_SHA256
CONFIG_CRYPTO_SHA512

Still no go. Later in the thread I found that I needed these options as well (Yes, I am using it as a block device):
CONFIG_BLK_DEV_DM
CONFIG_DM_CRYPT

Still no go. I started to get really annoyed, because, I had chosen to include a lot of the options in the kernel, so for each new try, I had to reboot the kernel. So, I searched for ‘algif’ in the thread and found that these options might also be needed:
CONFIG_CRYPTO_USER_API
CONFIG_CRYPTO_USER_API_HASH
CONFIG_CRYPTO_USER_API_SKCIPHER
.
I chose these options to be modules, and could load that module in right away, without a reboot. That did the trick.
There was some debate in the thread, whether you needed to include options in the kernel, or not, to be able to boot if your root is encrypted. I don’t have it setup that way, so it didn’t bother me, but somebody said it should be able to boot with the crypto options as modules, because modules can be loaded during boot.