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-obn...
> > 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.
--
/ Alexander Bokovoy