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-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.
The idea of having a separate config file was that the cockpit app
could then limit what is allowed to the only cases that work.
Ie it would not allow to create a domain controller it can't
successfully configure.
Of course it would conflict with an existing configured instance using
the regular configuration file, it means work on the cockpit app side
of course, that goes w/o saying.
I was merely offering a way to avoid clashes between cockpit and a
"proper" configuration, but there would still definitely be rough
edges.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc