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.
--
Simo Sorce
RHEL Crypto Team
Red Hat, In