reconsidering my (your?) current setup
With redhat 'dumping' the support for centos and the availability of containers. I thought about reconsidering my default dovecot setup.
Since the concept of having a lts distribution that is supported by redhat/centos is more or less 'unavailable'. I thought about using the repo of dovecot with centos8stream.
os
For now I stick with centos8stream, just because the rest is still on centos7 support and the ceph development team is using it as a default. (And can't yet let go of the idea this closest to professional distro ;))
auth uid gid os
I am not really convinced that storing users in mysql/postgres is a better alternative than having linux do auth. I also think it is good to have mailbox files stored with different uid's (no idea if this is even the case when dovecot is using mysql/maria/postgres)
Normally I would use a synced ldap server on the vm for authentication. But I was thinking of using now an external ldap task from the container environment. To de-duplicate services/data and make the environment simple. Since rh is moving to a different ldap server, it would be good to have this seperated in the future.
New to me is the sssd, used nscd/nslcd for decades without issues.
I guess the best solution is to have the os uid/gid coming from sssd, configure sssd to have a huge timeout if the backend ldap auth is not available. What is your thought about this?
auth uid gid dovecot
I do not really have an idea if I should have dovecot use ldap directly or use this sssd pam? The advantage of using ldap directly is you could maybe skip identifying users in the os. But maybe then tools like dovadm that require a user are not working anymore. From the keep it simple perspective it is probably better to use sssd. However centos8stream and sssd are not really known to me. So any ideas/advice about this?
Marc,
Have you heard of Rocky Linux[1]? Started by Gregory Kurtzer, founder of the CentOS project. You should give it a look.
Regards, Elisamuel Resto
On Oct 7, 2021, at 3:31 AM, Marc Marc@f1-outsourcing.eu wrote:
With redhat 'dumping' the support for centos and the availability of containers. I thought about reconsidering my default dovecot setup.
Since the concept of having a lts distribution that is supported by redhat/centos is more or less 'unavailable'. I thought about using the repo of dovecot with centos8stream.
os
For now I stick with centos8stream, just because the rest is still on centos7 support and the ceph development team is using it as a default. (And can't yet let go of the idea this closest to professional distro ;))
auth uid gid os
I am not really convinced that storing users in mysql/postgres is a better alternative than having linux do auth. I also think it is good to have mailbox files stored with different uid's (no idea if this is even the case when dovecot is using mysql/maria/postgres)
Normally I would use a synced ldap server on the vm for authentication. But I was thinking of using now an external ldap task from the container environment. To de-duplicate services/data and make the environment simple. Since rh is moving to a different ldap server, it would be good to have this seperated in the future.
New to me is the sssd, used nscd/nslcd for decades without issues.
I guess the best solution is to have the os uid/gid coming from sssd, configure sssd to have a huge timeout if the backend ldap auth is not available. What is your thought about this?
auth uid gid dovecot
I do not really have an idea if I should have dovecot use ldap directly or use this sssd pam? The advantage of using ldap directly is you could maybe skip identifying users in the os. But maybe then tools like dovadm that require a user are not working anymore. From the keep it simple perspective it is probably better to use sssd. However centos8stream and sssd are not really known to me. So any ideas/advice about this?
On 10-07-2021 4:30 am, Marc wrote: With redhat 'dumping' the support for centos and the availability of containers. I thought about reconsidering my default dovecot setup.
Since the concept of having a lts distribution that is supported by redhat/centos is more or less 'unavailable'. I thought about using the repo of dovecot with centos8stream.
Im surprised at how little people are aware of this. Oracle linux has been around since 2006 and is an exact port of RHEL. The only difference between Centos and Oracle is the repos. You can migrate your current Centos to Oracle by only changing out the repo files in /etc/yum.repos.d/
Ive been using Oracle Linux for about a year now beside Centos8 setting up identical services on both servers to experience if there are any differences. Everything has translated over 1:1 between both. Every command has been identical except for the names of adding repos. For example:
Centos8: dnf config-manager --set-enabled PowerTools
Oracle8: dnf config-manager --set-enabled ol8_codeready_builderBut after you add in the repo, the package names for services are identical so you can use the same dnf install commands on both.
On 07.10.21 13:49, dovecot@ptld.com wrote:
Im surprised at how little people are aware of this.
probably people are aware ... it's just that it is oracle *cough*cough* *scnr*. As RHEL clone there is also alma linux, rocky linux and eurolinux ... and various migration scripts [1]. However, with Linux distros it is up to your requirements, we do prefer Debian based distros and have had dovecot running on Ubuntu for a long time but have recently migrated to FreeBSD.
[1] https://github.com/AlmaLinux/almalinux-deploy
https://github.com/rocky-linux/rocky-tools/tree/main/migrate2rocky
AlmaLinux?
On 2021-10-07 1:30 a.m., Marc wrote:
With redhat 'dumping' the support for centos and the availability of containers. I thought about reconsidering my default dovecot setup.
Since the concept of having a lts distribution that is supported by redhat/centos is more or less 'unavailable'. I thought about using the repo of dovecot with centos8stream.
os
For now I stick with centos8stream, just because the rest is still on centos7 support and the ceph development team is using it as a default. (And can't yet let go of the idea this closest to professional distro ;))
auth uid gid os
I am not really convinced that storing users in mysql/postgres is a better alternative than having linux do auth. I also think it is good to have mailbox files stored with different uid's (no idea if this is even the case when dovecot is using mysql/maria/postgres)
Normally I would use a synced ldap server on the vm for authentication. But I was thinking of using now an external ldap task from the container environment. To de-duplicate services/data and make the environment simple. Since rh is moving to a different ldap server, it would be good to have this seperated in the future.
New to me is the sssd, used nscd/nslcd for decades without issues.
I guess the best solution is to have the os uid/gid coming from sssd, configure sssd to have a huge timeout if the backend ldap auth is not available. What is your thought about this?
auth uid gid dovecot
I do not really have an idea if I should have dovecot use ldap directly or use this sssd pam? The advantage of using ldap directly is you could maybe skip identifying users in the os. But maybe then tools like dovadm that require a user are not working anymore. From the keep it simple perspective it is probably better to use sssd. However centos8stream and sssd are not really known to me. So any ideas/advice about this?
-- "Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
The CentOS community manager is a friend and he understands that they really missed the mark on the messaging around CentOS8 Stream. In short, I'm not sure it's going to be that bad of a solution. The doom and gloom and concerns it would be untested, rawhide-esque solution was definitely misplaced. Not sure about the container concepts though and we've been testing with AlmaLinux too!
HTH, KAM
On 10/7/2021 11:39 AM, Michael Peddemors wrote:
AlmaLinux?
On 2021-10-07 1:30 a.m., Marc wrote:
With redhat 'dumping' the support for centos and the availability of containers. I thought about reconsidering my default dovecot setup.
Since the concept of having a lts distribution that is supported by redhat/centos is more or less 'unavailable'. I thought about using the repo of dovecot with centos8stream.
--
PCCCLogo https://www.pccc.com/ RaptorLogo https://raptoremailsecurity.com/
*Kevin A. McGrail- /CEO Emeritus / *Peregrine Computer Consultants Corporation
- Phone +1.703.798.0171 email KMcGrail@pccc.com Globe www.pccc.com Globe www.raptoremailsecurity.com
Location 10311 Cascade Lane, Fairfax, VA 22032
LinkedIn https://linkedin.com/in/kmcgrail Twitter https://twitter.com/kamcgrail
On 10-07-2021 11:57 am, Kevin A. McGrail wrote: The CentOS community manager is a friend and he understands that they really missed the mark on the messaging around CentOS8 Stream. In short, I'm not sure it's going to be that bad of a solution.
People think that because Redhat has repeatedly said stream is not Centos or a replacement for Centos.
https://www.redhat.com/en/resources/centos-stream-checklist says: "CentOS Stream may seem like a natural choice to replace CentOS Linux, but it is not designed for production use and can present many challenges in enterprise environments."
The CentOS community manager is a friend and he understands that they really missed the mark on the messaging around CentOS8 Stream. In short, I'm not sure it's going to be that bad of a solution.
People think that because Redhat has repeatedly said stream is not Centos or a replacement for Centos.
https://www.redhat.com/en/resources/centos-stream-checklist says: "CentOS Stream may seem like a natural choice to replace CentOS Linux, but it is not designed for production use and can present many challenges in enterprise environments."
Unfortunately that is true, they broke systemd-nspawn in CentOS Stream a while ago. It's a bad surprise when you update, reboot and your virtual servers don't work anymore. (systemd-nspawn is more like openvz used to be, something between docker/podman and qemu/kvm).
RockyLinux is an alternative for me although some extra repos like glusterfs (storage sig) are still missing.
Best regards Gerald
participants (7)
-
dovecot＠ptld.com
-
Elisamuel Resto
-
Gerald Galster
-
Infoomatic
-
Kevin A. McGrail
-
Marc
-
Michael Peddemors