This says nothing about a typical slackerware user's usecases. You are implying that "corporate office" are the typical server side usecases, but there are loads of server-software which don't need that at all.

Missing pam/kerberos/etc. in slackware does not necessarily mean it misses that feature, for many users it is of no use and just a drawback, for various already discussed and known reasons.

They usually pay for support, or for certified distributions forced by some software.

As said above, i don't think there is more income for Pat with Pam/Kerberos.

I think that what @Darth Vader imply is that the car factory (Patrick) does not make pink cars (Slackware with PAM/Kerberos) because Patrick is aware that those pink cars sales will flop (a part of existent buyers will refuse to buy it again or will cancel their subscriptions) and consequently he blame the car buyers (and their questionable taste, from his POV) for the lack of availability to buy pink cars.

You interpreted exactly contrary his words.

That assume that you know the typical Slackware user's usecases, did you? You made detailed statistics about the Slackware usage in the World?

How I am an ignorant, excuse me if I will put my trust in the words of Eric Hameleers, who claim that Slackware is a Swiss Army Knife, then an universal tool.

That imply it could be used well also in corporate office, and looks like the same thinks the OP of this thread.

I said "This says nothing about a typical slackerware user's usecases", nothing more.
From my pov i replied on @Darthvader's post where he wanted to say something about slackware usecases.

I do not think that someone can quantify the "typical slackerware user's usecases", eventually Patrick could make (for his own use) in his own business a questionnaire to know himself what usage is between those who pay subscriptions or buy DVDs.

BUT, we, here, in this forum, we represent really all the Slackware users and world-wide, then could be made in this forum a poll to quantify this information? I do not think so.

For example, we know that in Brazil is an active and numerous community of Slackware users. How many of them are here? Few, looking in that other thread.

Also, I know well that in Romania, years ago, in every city, in every block of apartments, there was a Slackware based router. Why Slackware? Who know? Maybe someone built a prototype like this, then it was mass reproduced by those interested.

Then, there are/was legions of Romanian guys who use(d) Slackware. How many Romanians are present here? Me, and looking in that another thread, another guy from Moldavia, which also speaks Romanian (Romania and Moldavia speaks same language).

And this way we can continue at infinite.

Do you really need to run your mail server on the same machine that runs your ADDC ?!?

If for whatever reason you have to use the same machine and you want to keep the stock Slackware, then use a container or a chroot.
Here is an example setup of LDAP+Kerberos SSO with SSH HTTP SMTP IMAP.
Here is an example of Samba ADDC and apache with mod_auth_kerb

Dovecot and exim packages here come with GSSAPI in the config dovecot.conf exim.conf


Cheers

2 members found this post helpful.

Ivandi: Thanks for actually responding to the thread issue! I will definitely check out those example links. No, I don't have to run the mail server on the AD/DC, but I'd rather. I was used to everything being on our old SBS2008 server which was much less powerful and seemed to have no problem. This server is quite powerful and, aside from authenticating when users log in, has nothing otherwise to do. Maybe a container, or VM is an idea. The Samba folks are discouraging about using the AD/DC for any such services as well. Really, all I need is for Sendmail to authenticate. I'll explore.

1 members found this post helpful.

http://www.sendmail.org/~ca/email/cyrus2/gssapi.html

The stock cyrus-sasl in Slackware is not compiled with gssapi support. You will have to at least install kerberos and recompile cyrus.


Cheers

1 members found this post helpful.

One thing I've read about SAMBA 4 as a DC, and I believe this is what you're referencing in the quoted text above mfoley, is that the Samba team does not recommend using a DC as a file server ( see the 3nd-to-last topic from the End, just before the Troubleshooting section )

OTOH, if one wants to shoot one's self in the foot, the SAMBA developers do provide links so that one can ready, fire, aim their foot off

The recommended deployment for SAMBA 4 as a DC might indicate a different Network Architecture for SAMBA on Linux compared to a LAN with an MS Windows SBS AD DC.

This is because a MS Windows SBS Box provides 'the kitchen sink of services' all on one-and-only-one box on the LAN while a SAMBA 4 DC on LINUX provides only DC Services and nothing else.

If one sets up a dedicated DC on SAMBA 4, how much horsepower would it actually need ?

Since all the SAMBA 4 DC really does is Authenticate Users for other Boxes on the LAN, it seems that the SAMBA 4 DC ought to be able to run on a relatively low-power system ( even on a larger installation )?

In that case, maybe a container or a VM is the way to go for the SAMBA 4 AD DC and then run your File-and-Printer Sharing, Email, etc on a Domain Member Box with all that HorsePower ?

Just wondering out loud ...

With the Magpie Filters applied, there's some Good Stuff in this Thread and thanks to ivandi for the links and as always, thanks to ivandi for all the PAM + Kerberos + SAMBA Packages for Slackware64 !

-- kjh

p.s. I've not set up a Slackware64 SAMBA AD DC in production yet ( only on the Bench in our Lab using ivandi's packages and only with three AD Users for testing )

In our case, the SAMBA 4 AD DC was just idling along not doing much at all, even when it actually had to Authenticate someone on the Domain ...

And as far as our Real-World needs among our Customer base, we either Join our Server Appliances to an existing Windows-Server-Hosted AD DC or when the Customer does not run an AD DC, we simply set up local users for LogIn and SAMBA on our Server Appliances.

@kjhambrick

What I do not understand what OP try to do, is because as I know, to authenticate to an AD, you should use Kerberos.

It is plain simple, this thing do the authentication to AD, have no importance the final client (mailer, web server, etc).

Yet, he try to avoid that.

Darth Vader --

Yes, ivandi has provided a very nice SlackBuild System to recompile essential Slackware 14.2 Packages so that they've got the extra PAM + Kerberos + LDAP components that one needs linked into the replacement Packages.

If you prefer, ivandi also provides the same binary packages and he keeps them updated too

I believe this is what mfoley is running ... we had a few longish threads here on LQ about it last spring ( or maybe even before then ).

So thanks to ivandi's Packages and mfoley's Persistence, mfoley is actually able to do almost everything he needs to do with Slackware and AD ...

This thread is about getting sendmail working on the otherwise-working Slackware + ivandi AD DC Server ...

I believe the issue is, while the Packages on the SAMBA 4 AD DC can serve up Authentication to other Hosts on the AD Domain, most of the Apps on the AD DC box are not AD-Ready and may not even be AD Capable.

Moreover, it sounds like the SAMBA Team discourages setting up a SAMBA AD DC as anything BUT the AD DC ( at least they do explicitly discourage file sharing on the AD DC ).

Anyhow ... I believe that's where we're at with the tech stuff on this thread ...

While I am here ... I wonder if something tiny and cheap like a Raspberry Pi 3 would be capable of running SAMBA 4 AD DC Services for a moderately sized AD Domain ???

There seem to be a lot of links in google-land indicating that it might be so ...

-- kjh

I know about Ivandi's brilliant work and I am very grateful to him.

BUT, I for one, I would rebuild that Sendmail with Kerberos support. (see @mfoley)

Honestly? Because I hate with passion the Sendmail configuration, I would look in Patrick's -current and shameless borrow the Postfix and Dovecot, then adapt them to my particular environment. Also they have Kerberos support.

BUT, that's a personal preference, not really required.

Then:

I really wish the "No" option was returned to the Did you find this post helpful? when I read things such as the above. (And you could return the favor when you read things such as this!)

1 members found this post helpful.

Well, Slackware was a Swiss Army Knife. I remember that. But it was "long time ago in a galaxy far, far away". Nowadays Slackware is barely a bottle opener, and not the best one. We used to say that Slackware was Linux, but today it only resembles Linux. It still has a good toolchain and X, but the rest is a poor Windows Home imitation. A commercial distribution unusable in office environment. A toy to tinker with in your spare time.

Anyway, sorry for the OT.


Cheers

3 members found this post helpful.

You are right about sasl:
Kerberos *is* installed as part of the Samba4 AD setup. Samba4 supplies Heimdal Kerberos. I will certainly look at adding GSSAPI to saslauthd as a first step in this.
Very little!
All that is likely true. I am resisting that approach out of stubornness. I didn't like it when Microsoft came out with SBS2008 and made us move SQL Sever off the SBS machine (where it performed just fine under SBS2003), and I didn't like it when they came out with Server Essentials and made us move Exchange off the server. That's when I started exploring Samba4. I see no good reason that the AD Server cannot also be a mail server. As has been pointed out, what else does it have to do? So, that's my quest.
I've been running Samba4 as AD/DC in production for more than 3 years with Windows domain members and, thanks to Ivandi's PAM, I've added 2 Linux workstations for staff users. The AD has been serving email, DNS, DHCP, Windows redirected folders AND scanning incoming mail for virus/spam, scanning IMAP mail folders for viruses, and scanning redirected folders and user C: drives for new/changed files and testing against crytoWall, wannacry, etc. signature files. Oh yeah, and it's running an XP VM. It's running an Intel i7-4790K at 4.0MHz and still seems to register 70-80% idle. So, I WANT it to do mail!
There seems to be a general misunderstanding that Samba4 does not have kerberos. It does, and it uses that to authenticate locally and from domain members. I am not trying to avoid kerberos. All I am trying to do is get Sendmail (that is saslauthd) to authenticate with the AD. I'd be happy to use kerberos or GSSAPI (which might be the same thing).

Not to get into a religious discussion, but I've found the opposite to be true. I've tried setting up both the AD/DC and domain members using Debian and Ubuntu. In both cases the Samba shipped with Slackware was more recent the the Debian/Ubuntu repo versions. I was never able to quite get Samba4 working as AD/DC with Debian (likely mostly due to my inexpertise), but it worked out-of-the-box with Slackware. On Unbuntu, I had to apt-get install acl attr quota samba samba-vfs-modules samba-common-bin samba-common samba-libs libwbclient0 samba-dsdb-modules libnss-winbind smbclient libpam-winbind libsmbclient winbind krb5-config libpam-krb5 krb5-user ssh-krb5 ntp ldb-tools nfs-common nfs-kernel-server autofs ssh gnome-icon-theme-full gthumb thunar cinnamon heirloom-mailx cifs-utils, whereas the only additional component I needed for Slackware was Ivandi's PAM. Furthermore, the Ubuntu KDE was fraught with trouble whereas KDE worked out-of-the-box with Slackware (KDE to prevent user-shock/rejection using Linux versus Windows). Slackware is bullet-proof. It never goes down. I consider Slackware the best choice for Office/production and have been using it in a server capacity (webserver, NAS) for over 10 years.

But, to each their own! Ivani's opinion cannot be gainsaid.

My next step is to investigate Invani's suggestion on recompiling cyrus-sasl with GSSAPI. Meanwhile, I've requested to join the cyrus-sasl maillist. Stay tooned!