Hi - On 9/20/21 09:51, Ralph Boehme wrote:> Am 20.09.21 um 16:42 schrieb Patrick Goetz via samba: >> Now it looks like I'm going to have to rethink the entire system >> architecture if I want to upgrade the file server from Ubuntu 18.04 to >> anything newer?? (Ubuntu 20.04 ships 4.11.6).? This is going to be a >> problem, as all the files are related to the UIDs and GIDs generated >> by sssd. I'm not sure that's realistic in a very active research >> environment. The solution is likely going to involve virtualizing all >> the Windows machines and using IOMMU to provide a PCIe passthrough for >> whatever GPU's they need for processing. > > sorry, tl;dr, at least not fully, but still wanted to mention... > >> Any thoughts on this appreciated. > > ...you could try to use the idmap sss backend. Unfortunately it's not > included in upstream Samba and therefor not available on Ubuntu. Otho > RHEL Samba ships it, if that helps. > > Alternatively you could build Samba packages from source and include the > necessary patches, I have a WIP branch here: > > <https://git.samba.org/?p=slow/samba.git;a=shortlog;h=refs/heads/idmap_sss> >I'm a bit confused about what this branch does; i.e. if it's just to facilitate the use of idmap_sss, then why are patches needed? Aren't people currently using idmap_sss with Samba, or is that only because Redhat is patching Samba downstream and it doesn't work at all with Ubuntu systems even when sss is installed? I've read there's a memory leak in 4.11 anyway, and some people are recommending the source: http://apt.van-belle.nl/ as an alternative to the distro Samba packages available on Debian/Ubuntu.> Cheers! > -slow > > > > This message is from an external sender. Learn more about why this > matters. <https://ut.service-now.com/sp?id=kb_article&number=KB0011401> > >
On Wed, 2021-09-22 at 11:00 -0500, Patrick Goetz via samba wrote:> Hi - > > On 9/20/21 09:51, Ralph Boehme wrote: > > Am 20.09.21 um 16:42 schrieb Patrick Goetz via samba: > > > Now it looks like I'm going to have to rethink the entire system > > > architecture if I want to upgrade the file server from Ubuntu > > > 18.04 to > > > anything newer? (Ubuntu 20.04 ships 4.11.6). This is going to > > > be a > > > problem, as all the files are related to the UIDs and GIDs > > > generated > > > by sssd. I'm not sure that's realistic in a very active research > > > environment. The solution is likely going to involve virtualizing > > > all > > > the Windows machines and using IOMMU to provide a PCIe > > > passthrough for > > > whatever GPU's they need for processing. > > > > sorry, tl;dr, at least not fully, but still wanted to mention... > > > > > Any thoughts on this appreciated. > > > > ...you could try to use the idmap sss backend. Unfortunately it's > > not > > included in upstream Samba and therefor not available on Ubuntu. > > Otho > > RHEL Samba ships it, if that helps. > > > > Alternatively you could build Samba packages from source and > > include the > > necessary patches, I have a WIP branch here: > > > > < > > https://git.samba.org/?p=slow/samba.git;a=shortlog;h=refs/heads/idmap_sss > > > > > > > I'm a bit confused about what this branch does; i.e. if it's just to > facilitate the use of idmap_sss, then why are patches needed? Aren't > people currently using idmap_sss with Samba, or is that only because > Redhat is patching Samba downstream and it doesn't work at all with > Ubuntu systems even when sss is installed?OK, if you read the red hat 8 documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/assembly_using-samba-as-a-server_deploying-different-types-of-servers It says this: Important Red Hat only supports running Samba as a server with the winbindd service to provide domain users and groups to the local system. Due to certain limitations, such as missing Windows access control list (ACL) support and NT LAN Manager (NTLM) fallback, SSSD is not supported. Or to put it another way, not even red hat supports using sssd with Samba.> > I've read there's a memory leak in 4.11 anyway, and some people are > recommending the source: http://apt.van-belle.nl/ > as an alternative to the distro Samba packages available on > Debian/Ubuntu.I can highly recommend Louis's repo. Rowland
Am 22.09.21 um 18:00 schrieb Patrick Goetz:> I'm a bit confused about what this branch does; i.e. if it's just to > facilitate the use of idmap_sss, then why are patches needed?it doesn't facilitat idmap_sss, it *adds* idmap_sss. It's a development branch forket from the main samba development branch where I've added the idmap_sss sources taken from the upstream sssd git repository.> Aren't people currently using idmap_sss with Samba,only on Redhat, because there Samba is patched to include idmap_sss. Other Linuxes ship vanilla upstream Samba that doesn't include idmap_sss.> or is that only > because Redhat is patching Samba downstream and it doesn't work at > all with Ubuntu systems even when sss is installed? > > I've read there's a memory leak in 4.11 anyway, and some people are > recommending the source: http://apt.van-belle.nl/ as an alternative > to the distro Samba packages available on Debian/Ubuntu.you will have to build your own packages on Ubuntu from source if you want to use idmap_sss. -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20210922/4f6220ea/OpenPGP_signature.sig>
On 9/22/21 12:00 PM, Patrick Goetz via samba wrote:> Hi - > > On 9/20/21 09:51, Ralph Boehme wrote: >> Am 20.09.21 um 16:42 schrieb Patrick Goetz via samba: >>> Now it looks like I'm going to have to rethink the entire system >>> architecture if I want to upgrade the file server from Ubuntu 18.04 >>> to anything newer?? (Ubuntu 20.04 ships 4.11.6).? This is going to be >>> a problem, as all the files are related to the UIDs and GIDs >>> generated by sssd. I'm not sure that's realistic in a very active >>> research environment. The solution is likely going to involve >>> virtualizing all the Windows machines and using IOMMU to provide a >>> PCIe passthrough for whatever GPU's they need for processing. >> >> sorry, tl;dr, at least not fully, but still wanted to mention... >> >>> Any thoughts on this appreciated. >> >> ...you could try to use the idmap sss backend. Unfortunately it's not >> included in upstream Samba and therefor not available on Ubuntu. Otho >> RHEL Samba ships it, if that helps. >> >> Alternatively you could build Samba packages from source and include >> the necessary patches, I have a WIP branch here: >> >> <https://git.samba.org/?p=slow/samba.git;a=shortlog;h=refs/heads/idmap_sss> >> >> > > I'm a bit confused about what this branch does; i.e. if it's just to > facilitate the use of idmap_sss, then why are patches needed? Aren't > people currently using idmap_sss with Samba, or is that only because > Redhat is patching Samba downstream and it doesn't work at all with > Ubuntu systems even when sss is installed?SSSD winbind idmap is part of SSSD, you need a SSSD built with the configure --with-samba flag. Red Hat distributions enable that flag, others maybe not. Source code at https://pagure.io/SSSD/sssd/blob/master/f/src/lib/winbind_idmap_sss> > I've read there's a memory leak in 4.11 anyway, and some people are > recommending the source: http://apt.van-belle.nl/ > as an alternative to the distro Samba packages available on Debian/Ubuntu. > > >> Cheers! >> -slow >> >> >> >> This message is from an external sender. Learn more about why this >> matters. <https://ut.service-now.com/sp?id=kb_article&number=KB0011401> >> >> >