• 2 Posts
  • 8 Comments
Joined 1 month ago
cake
Cake day: October 20th, 2024

help-circle

  • Hm, with that setup I always have dovecot complaining that it couldn’t read /etc/shadow despite me adding dovecot to the shadow group and /etc/shadow having the permissions

    -rw-r-----    1 root     shadow         699 Nov  2 23:13 /etc/shadow
    

    I ended up following the configuration here and manually managing an /etc/dovecot/passwd file with users and hashed passwords. With this setup I could log in and read my emails in Thunderbird.

    Thanks for your help though! Even though I couldn’t figure out how to set up using UNIX account password authentication, you still helped me figure out that the passdb/userdb settings were the issue so I could keep trying different options till they worked. And I suppose at least this method avoids the security concern of letting dovecot read my entire /etc/shadow file.




  • Hm, still no luck. I now have

    passdb {
      driver = passwd
    }
    userdb {
      driver = passwd
    }
    

    to be as simple as I can. I’m now getting

    Nov 02 21:11:06 auth: Debug: Read auth token secret from /run/dovecot/auth-token-secret.dat
    Nov 02 21:11:06 auth: Debug: auth client connected (pid=12662)
    Nov 02 21:11:06 auth: Debug: client in: AUTH    1       PLAIN   service=imap    secured=tls     session=JNRsffQlRuXBIH/a        lip=<server IP>       rip=<home IP>      lport=993       rport=58694     local_name=mail.domain.com
    Nov 02 21:11:06 auth: Debug: client passdb out: CONT    1       
    Nov 02 21:11:06 auth: Debug: client in: CONT<hidden>
    Nov 02 21:11:06 auth: Debug: passwd(user,<home IP>,<JNRsffQlRuXBIH/a>): Performing passdb lookup
    Nov 02 21:11:06 auth-worker(12667): Debug: Loading modules from directory: /usr/lib/dovecot/auth
    Nov 02 21:11:06 auth-worker(12667): Debug: Module loaded: /usr/lib/dovecot/auth/lib20_auth_var_expand_crypt.so
    Nov 02 21:11:06 auth-worker(12667): Debug: conn unix:auth-worker (pid=12664,uid=90): Server accepted connection (fd=13)
    Nov 02 21:11:06 auth-worker(12667): Debug: conn unix:auth-worker (pid=12664,uid=90): Sending version handshake
    Nov 02 21:11:06 auth-worker(12667): Debug: conn unix:auth-worker (pid=12664,uid=90): auth-worker<1>: Handling PASSV request
    Nov 02 21:11:06 auth-worker(12667): Debug: conn unix:auth-worker (pid=12664,uid=90): auth-worker<1>: passwd(user,<home IP>,<JNRsffQlRuXBIH/a>): Performing passdb lookup
    Nov 02 21:11:06 auth-worker(12667): Debug: conn unix:auth-worker (pid=12664,uid=90): auth-worker<1>: passwd(user,<home IP>,<JNRsffQlRuXBIH/a>): lookup
    Nov 02 21:11:06 auth-worker(12667): Info: conn unix:auth-worker (pid=12664,uid=90): auth-worker<1>: passwd(user,<home IP>,<JNRsffQlRuXBIH/a>): Password mismatch
    Nov 02 21:11:06 auth-worker(12667): Debug: conn unix:auth-worker (pid=12664,uid=90): auth-worker<1>: passwd(user,<home IP>,<JNRsffQlRuXBIH/a>): Finished passdb lookup
    Nov 02 21:11:06 auth-worker(12667): Debug: conn unix:auth-worker (pid=12664,uid=90): auth-worker<1>: Finished: password_mismatch
    Nov 02 21:11:06 auth: Debug: passwd(user,<home IP>,<JNRsffQlRuXBIH/a>): Finished passdb lookup
    Nov 02 21:11:06 auth: Debug: auth(user,<home IP>,<JNRsffQlRuXBIH/a>): Auth request finished
    Nov 02 21:11:08 auth: Debug: client passdb out: FAIL    1       user=user
    

    In my dovecot logs. It claims a password mismatch, but I am pretty sure the password is the password to my UNIX user, copy and pasted from my password manager. I can log into my user through VNC by pasting this password and authenticate doas with this password, so unless it somehow pastes differently into Thunderbird…

    I also tried authenticating with PAM instead but got

    Nov 02 21:03:23 auth: Debug: Loading modules from directory: /usr/lib/dovecot/auth
    Nov 02 21:03:23 auth: Fatal: Support not compiled in for passdb driver 'pam'
    

    So I guess unfortunately the dovecot binary Alpine distributes doesn’t support pam. I might try install a version compiled with pam support just to test it but I’d rather just use the dovecot from my package manager if I can get it to work.

    Have you set up the users in that file (/etc/dovecot/users) if you even want to do that instead of just using passwd?

    Yep I do want to use passwd/UNIX users, not a users file. Thanks for pointing that out—the tutorial didn’t mention it so I assumed I didn’t need to change that to get it working with UNIX users.

    What do you have your passdb set to if you don’t mind me asking?


  • Thanks, I added $mydomain to mydestination. It seems to be sending although I can’t see my mail in ~/Maildir, but this is in the syslog now:

    Nov  2 20:45:46 domain mail.info postfix/smtpd[29768]: Anonymous TLS connection es
    tablished from mail-43167.protonmail.ch[185.70.43.167]: TLSv1.3 with cipher TLS_AES_
    256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1
    ) server-digest SHA256
    Nov  2 20:45:46 domain mail.info postfix/smtpd[29768]: C2E9F125DF5: client=mail-43
    167.protonmail.ch[185.70.43.167]
    Nov  2 20:45:46 domain mail.info postfix/cleanup[29773]: C2E9F125DF5: message-id=<
    id@protonmail.com>
    Nov  2 20:45:46 domain mail.info postfix/qmgr[29128]: C2E9F125DF5: from=<my@
    protonmail.com>, size=5933, nrcpt=1 (queue active)
    Nov  2 20:45:46 domain mail.info postfix/smtpd[29768]: disconnect from mail-43167.
    protonmail.ch[185.70.43.167] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=
    7
    Nov  2 20:45:46 domain mail.info postfix/local[29775]: C2E9F125DF5: passing <user@
    domain.com> to transport=lmtp
    Nov  2 20:45:46 domain mail.info postfix/lmtp[29776]: C2E9F125DF5: to=<user@domain.c
    om>, relay=none, delay=0.05, delays=0.04/0.01/0.01/0, dsn=4.4.1, status=deferred
     (connect to mail.domain.com[private/dovecot-lmtp]: No such file or directory)
    

    I think the last message in the log indicates what’s wrong but I don’t know how to fix it.

    You’ll want those to match up, system hostname and postfix’s myhostname, since you’ll need to set the PTR record of your IP to match the hostname your SMTP server identifies itself as, and otherwise your server’s IP resolves to mail.domain.com while the canonical hostname is domain.com. It will work for mail, it’ll just not be nice when your server’s IP resolves to mail.domain.com for stuff that isn’t mail and that isn’t the canonical hostname. I recommend giving it some other hostname (or just setting both to mail.domain.com if the system just handles mail).

    So I have the mail server on a server that’s hosting a bunch of things on this domain. All the things I’m hosting have the same IP address. On domain.com is a static website (hosted on the same server & IP) for instance.

    What would you suggest I set the PTR record to? I don’t really want to pay my VPS host for more IP addresses if it’s not necessary, but I can if there will be significant problems caused by sharing this IP address. Currently I have multiple PTR records for all the subdomains I’m using, which hasn’t caused problems yet…



  • I wanted to reply just as an update as I finally got round to migrating my Nextcloud instance to be behind nginx, and should anyone else stumble upon this thread maybe this will help you.

    I think you misunderstood my question btw but don’t worry, I figured it out anyway.

    My question was about whether or not I could transfer my Nextcloud instance (including data) to be behind a reverse proxy. The answer is simply yes, you can use the same Docker volumes and it’ll be the “same” Nextcloud instance (ie exact same config, user data, etc, no need to set anything up again).

    If you’ve already followed these instructions on a server that doesn’t already have a web server running, just take your containers down and follow Nextcloud AIO’s reverse proxy guide. If you use the commands suggested in both guides, the volume names will be the same, so the new docker container will use the same volume that the old docker container used. You’ll have to delete or rename the old containers so Docker doesn’t complain about a container by the same name already existing.