On ke, 13 huhti 2022, Simo Sorce wrote:
On Wed, 2022-04-13 at 07:47 +0300, Alexander Bokovoy wrote:
On ti, 12 huhti 2022, Matthew Miller wrote:
On Mon, Apr 11, 2022 at 08:43:25PM +0200, Peter Boy wrote:
I'd love to have a more slick solution here, but it requires some development (and possibly some changes to samba packaging). I definitely don't have time for that, but I can throw ideas at anyone who is interested in working on it.
And I would be eager to get to know those ideas. I can’t do that work either, I suppose, but we can develop a more or less detailed and „overseeable“ project plan. And I'm optimistic that we will someone stepping up to make it happen.
I'd like it to be automated as possible, so, first, if the proper RPMs aren't installed, each tab should include a button which will cause them to be installed. That part is fairly straightforward.
The more complicated part is the configuration. The tool works by using Samba's ability to read its config from a Windows-like registry. This is a pretty big change. There may be later docs — I'm not a Samba expert _at all_ — but https://www.samba.org/~obnox/presentations/linux-kongress-2008/lk2008-obnox.... gives some detail which is probably still mostly relevant. The section on disadvantages of the text-file config approach is particularly relevant, and particuarly:
"""
When changing one parameter, the whole configuration needs to be written and re-read.
When writing application such as GUIs for configuring Samba, one always has to write whole configuration files. There is no procetion for concurrent access to the configuration file by multiple porocesses. For a certain level of safety, applications need to prepare their own temporary version of the configuration file and copy it over the real one. Other applications may overwrite your changes
"""
Right now, the setup uses "mixed mode", where the tool asks you to add "include = registry" in the config. I think we should instead make it so that it uses the _entirely_ registry-based mode, with "config backend = registry".
I think that if the Samba package config file is unmodified, the tool should replace that unmodified config file with one that just has this minimal config pointing to the registry (along with a suitable comment). If, on the other hand, the config is non-default, the tool should warn and _offer_ to do that, noting that it will replace existing configuration (and of course, it should make a backup).
Please do not do that unconditionally. As I said already first time we discussed this topic, use of the registry is not compatible with several Samba modes and should not be done automatically. Even if user has installed a cockpit plugin, it does not mean that configuration has to be changed.
If anything, this has to be driven through the Cockpit app's page with an additional wizard there. You are going to get a lot of subtle bugs otherwise which are hard to diagnoze and solve. As Samba and FreeIPA maintainer in Fedora I am one of those who will have to work with those bugs and I do not want to tell people they broke their installations by installing a cockpit app plugin. We already have enough problems with FAS plugin to FreeIPA which unconditionally changes critical configuration settings.
Alexander, Matthew, maybe a better way forward is for the cockpit plugin to create a separate config file and then create a custom systemd unit file that tells samba to use this alternative configuration file.
If file serving is managed via cockpit then the cockpit-samba.service with its own special config will be used and be happy.
Of course if something enables the "standard" samba service this needs to conflict with cockpit-samba.service and cockpit can tell the user they need to disable the other service or use manual configs or something.
At least there will not be conflicts in messing with config files.
Simo,
it is not about configuration file. It was never about that. Remember that Samba is a bunch of databases that cannot really be relocated.
It is basically one service type at a time. Either you are domain member or you are a domain controller. You can be a standalone service too. If you are domain controller or a standalone service, then certain settings not only enforced but some behavior is enforced too, especially around Kerberos. With Samba AD DC, there are some shares that should have specific VFS modules set up on them if you want to provide expected behavior for Windows clients and so on. For FreeIPA domain controller there is a particular combination of settings, modules, and databases that define it. Out of all modes, Samba AD DC is not compatible with the registry configuration at all.
The cockpit app in question knows nothing about that. It was designed for a specific use case of a specific vendor solution. We are pushing it as an easy mechanism to manage Samba and NFS shares on a domain member or standalone Fedora workstation. However, installing package and using it has no artificial limits and that means sooner or later we'll see bug reports on 'Samba broke' or 'Cockpit app for Samba does not work'.
I am not against an app in itself, what I am asking for is for it to behave as a good citizen in Fedora ecosystem. If maintainers cannot handle that, by contributing upstream or handling discussions with its upstream for adding such behavior, it would be a bit appalling and questionable why it should be present in Fedora.