I did some testing with beta-1.1 candidate
Installation Went fine. /etc/resolv.conf a link again, no SELinux ACV messages with first boot any more.
Cockpit The „Applications“ menu item still doesn’t list any installable applications The list of installed applications doesn’t contain cockpit-filesharing update. Question is: is that expected or a bug?
@Matthew: When you select File Sharing you get a message "Failed to load NFS services. Is NFS installed or enabled?" (NFS) and "Samba must be configured to include registry. Add `include = registry` to the [global] section of /etc/samba/smb.conf“ (Samba)
Is that intended behaviour or should the rpm install do those adaptations?
And we are still missing localisation for cockpit-filesharing update
Virtualization
Installs flawlessly. The combo of qemu-kvm-core, libvirt, and virt-install now installs 104 packages on a fresh install, instead of 165 with beta 1.1 candidate. Either we will miss something or someone did a great job in housekeeping.
Split name resolution doesn’t work for the libvirt internal network. I’ve to inspect that issue further. Possibly the configuration is still deficient (and not any of the apps).
postgresql installed flawless
Best Peter
On Sun, Mar 20, 2022 at 8:23 AM Peter Boy pboy@uni-bremen.de wrote:
I did some testing with beta-1.1 candidate
Installation Went fine. /etc/resolv.conf a link again, no SELinux ACV messages with first boot any more.
Cockpit The „Applications“ menu item still doesn’t list any installable applications The list of installed applications doesn’t contain cockpit-filesharing update. Question is: is that expected or a bug?
This is expected today. No one has written the necessary bits to list it on that page. See https://cockpit-project.org/blog/making-a-cockpit-application.html for the necessary steps.
@Matthew: When you select File Sharing you get a message "Failed to load NFS services. Is NFS installed or enabled?" (NFS) and "Samba must be configured to include registry. Add `include = registry` to the [global] section of /etc/samba/smb.conf“ (Samba)
Is that intended behaviour or should the rpm install do those adaptations?
It's intentional, because we don't want the installation of the RPM to change the system configuration implicitly. As for the Samba changes, adding `include = registry` is a significant change to how Samba works and should not be done without user involvement to avoid breaking an existing setup.
And we are still missing localisation for cockpit-filesharing update
This is something I forgot to even look at, sorry.
Am 21.03.2022 um 19:48 schrieb Stephen Gallagher sgallagh@redhat.com:
On Sun, Mar 20, 2022 at 8:23 AM Peter Boy pboy@uni-bremen.de wrote:
Cockpit The „Applications“ menu item still doesn’t list any installable applications The list of installed applications doesn’t contain cockpit-filesharing update. Question is: is that expected or a bug?
This is expected today. No one has written the necessary bits to list it on that page. See https://cockpit-project.org/blog/making-a-cockpit-application.html for the necessary steps.
At first glance, it doesn't seem that elaborate. If I remember correctly, there is some interest in getting into the technical details. Maybe someone can be found for an update.
(wave wave a big fence post)
@Matthew: When you select File Sharing you get a message "Failed to load NFS services. Is NFS installed or enabled?" (NFS) and "Samba must be configured to include registry. Add `include = registry` to the [global] section of /etc/samba/smb.conf“ (Samba)
Is that intended behaviour or should the rpm install do those adaptations?
It's intentional, because we don't want the installation of the RPM to change the system configuration implicitly. As for the Samba changes, adding `include = registry` is a significant change to how Samba works and should not be done without user involvement to avoid breaking an existing setup.
I wrote a stub of a documentation:
Managing file sharing using Cockpit https://docs.stg.fedoraproject.org/en-US/fedora-server/service-filesharing-c...
I use CentOS as an example.
To all our testers: I would be grateful for ideas and hints what else should go into this documentation. Especially Samba, my own experiences with it are about a decade ago.
And for NFS I miss the part about NFS 4.0 and the different authentication options.
And we are still missing localisation for cockpit-filesharing update
This is something I forgot to even look at, sorry.
A good point for an update, too.
Best Peter
Hello all,
Peter Boy [2022-03-25 0:52 +0100]:
This is expected today. No one has written the necessary bits to list it on that page. See https://cockpit-project.org/blog/making-a-cockpit-application.html for the necessary steps.
At first glance, it doesn't seem that elaborate. If I remember correctly, there is some interest in getting into the technical details. Maybe someone can be found for an update.
It's not that elaborate as there really isn't that much about it.
Cockpit's starter-kit [1] has the AppStream data bits. In particular, you need a metainfo file [2] and let the packaging drop that into /usr/share/metainfo/. starter-kit still does i18n in between [3], but that's just a glorified `cp`. Honestly, i18n is a bit of a lost cause in file-sharing (and would need a lot of work), so I suggest to just ignore that bit for now.
As a bonus, the RPM packaging (or some upstream CI) should make sure that the file is valid [4].
Martin
[1] https://github.com/cockpit-project/starter-kit/ [2] https://github.com/cockpit-project/starter-kit/blob/main/org.cockpit-project... [3] https://github.com/cockpit-project/starter-kit/blob/29abcaab98e8eb31cc1f32fa... [4] https://github.com/cockpit-project/starter-kit/blob/29abcaab98e8eb31cc1f32fa...
On Mon, Mar 21, 2022 at 02:48:46PM -0400, Stephen Gallagher wrote:
@Matthew: When you select File Sharing you get a message "Failed to load NFS services. Is NFS installed or enabled?" (NFS) and "Samba must be configured to include registry. Add `include = registry` to the [global] section of /etc/samba/smb.conf“ (Samba)
Is that intended behaviour or should the rpm install do those adaptations?
It's intentional, because we don't want the installation of the RPM to change the system configuration implicitly. As for the Samba changes, adding `include = registry` is a significant change to how Samba works and should not be done without user involvement to avoid breaking an existing setup.
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.
Am 11.04.2022 um 17:55 schrieb Matthew Miller mattdm@fedoraproject.org:
On Mon, Mar 21, 2022 at 02:48:46PM -0400, Stephen Gallagher wrote:
@Matthew: When you select File Sharing you get a message "Failed to load NFS services. Is NFS installed or enabled?" (NFS) and "Samba must be configured to include registry. Add `include = registry` to the [global] section of /etc/samba/smb.conf“ (Samba)
Is that intended behaviour or should the rpm install do those adaptations?
It's intentional, because we don't want the installation of the RPM to change the system configuration implicitly. As for the Samba changes, adding `include = registry` is a significant change to how Samba works and should not be done without user involvement to avoid breaking an existing setup.
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.
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).
And then it should start the service, of course. :)
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.
Am 13.04.2022 um 06:47 schrieb Alexander Bokovoy abbra@fedoraproject.org:
On ti, 12 huhti 2022, Matthew Miller wrote:
On Mon, Apr 11, 2022 at 08:43:25PM +0200, Peter Boy wrote:
...
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.
Do we have a Fedora specific Samba installation and administration guide elsewhere? I had just had a short look around and couldn’t find anything. If we would have a recommended way, couldn’t we work along that path?
And we don’t need to do it automatically. We could ask for permission beforehand.
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.
Developing an additional wizard might be a task for a specialist in Cockpit. What are possible alternatives to improve the current situation in this regard?
Peter
On ke, 13 huhti 2022, Peter Boy wrote:
Am 13.04.2022 um 06:47 schrieb Alexander Bokovoy abbra@fedoraproject.org:
On ti, 12 huhti 2022, Matthew Miller wrote:
On Mon, Apr 11, 2022 at 08:43:25PM +0200, Peter Boy wrote:
...
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.
Do we have a Fedora specific Samba installation and administration guide elsewhere? I had just had a short look around and couldn’t find anything. If we would have a recommended way, couldn’t we work along that path?
We do not have Fedora-specific guides nor I think we should have any. We have three major uses for Samba in Fedora:
- Samba as a domain member for Active Directory-like environment - Samba as an Active Directory domain controller - Samba as a standalone file server
For all these cases we have documentation elsewhere:
- on wiki.samba.org, for majority of Samba use cases
- RHEL documentation for both Samba and FreeIPA uses
Fedora does not differ much from anything else in all these cases except that we are traditionally a forefront of Samba AD DC using MIT Kerberos build. However, this is only a feature set difference and not actual configuration after you have deployed Samba AD. And with Fedora 37 we hope to get this feature set gap reduced completely.
Think of the documentation for Samba and FreeIPA as distribution-neutral similar to how systemd documentation is distribution neutral. Spending time to create Fedora-specific guides is counterproductive and disturbs activities of upstream projects which already are busy with more stuff they could cover realistically with existing resources.
In past, we had FreeIPA chapters in Fedora 18 or so. These proved to be quite problematic: they are outdated and irrelevant content-wise but they keep appearing in search engines' results because Fedora documentation content has good SEO ratings. It is impossible to remove them, unfortunately, and we had to deal with a lot of users following those outdated recipes and literally breaking their deployments.
And we don’t need to do it automatically. We could ask for permission beforehand.
I don't think you are realising what you are asking for here. There could be no interactive permission ask anywhere other than in Cockpit app itself. RPM installation is non-interactive and there are no other means to add interactivity into any setup.
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.
Developing an additional wizard might be a task for a specialist in Cockpit. What are possible alternatives to improve the current situation in this regard?
There is no alternative for interactive setup. Either you have it when Cockpit app is provided or you don't because there is no other place where you could ask for this permission otherwise.
I would suggest those who want to improve this Samba Cockpit app is to focus your effort in upstream and either contribute this helper to the app upstream or explain to existing developers why it is important to add it. The original use for them was to set it up on a specialized distribution where they control all configuration files themselves, so for them it was not really needed. Making this feature upstream would also help in future as you wouldn't need to maintain a downstream patch.
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.
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.
On Wed, 2022-04-13 at 20:41 +0300, Alexander Bokovoy wrote:
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.
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.
On ke, 13 huhti 2022, Simo Sorce wrote:
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.
I understand what you have proposed. I have pointed that it is not possible because not everything can be overridden from such config and, sadly, those bits are what common to all configurations. Content in /var/lib/samba is what matters, not where config file is located.
On Thu, 2022-04-14 at 07:29 +0300, Alexander Bokovoy wrote:
On ke, 13 huhti 2022, Simo Sorce wrote:
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.
I understand what you have proposed. I have pointed that it is not possible because not everything can be overridden from such config and, sadly, those bits are what common to all configurations. Content in /var/lib/samba is what matters, not where config file is located.
Well technically cockpit can easily override that too, by chrooting/bind mounting stuff around in the init script as well, but this quickly becomes a cat&mouse chase and probably a mess. And if anything goes wrong it will be hard to figure out what happened. Ignore my suggestion.
Simo.
On Thu, Apr 14, 2022 at 07:29:48AM +0300, Alexander Bokovoy wrote:
I understand what you have proposed. I have pointed that it is not possible because not everything can be overridden from such config and, sadly, those bits are what common to all configurations. Content in /var/lib/samba is what matters, not where config file is located.
I think in the overwhelming number of cases I care about, samba will not have any previous configuration. I would be perfectly fine with the plugin recognizing anything other than:
1) whatever is the default out of the box 2) its own configuration
... and then displaying something like "This system has already been configured for advanced file sharing. It can't be managed via this interface. If this isn't what you want, remove all existing configuration and return here."
Hello all,
you can ignore everything below, since I am neither a software maintainer for Fedora nor Developer of Cockpit. Therefore, let me thank you for the awesome work you are doing and the value you are adding.
I was following the whole discussion of Cockpit-Samba/NFS integration. From my perspective, it is a nice feature to have (in the future) and maybe even a cool use case for some users. Nevertheless, we have to keep in mind, that there are some very prominent statements in the room for both, Fedora and Cockpit, that will be taken as a promise from users:
## From the Cockpit Project Landing Page:
Cockpit uses APIs that already exist on the system. It doesn’t reinvent subsystems or add a layer of its own tooling.
## From the Fedora Foundations (Features):
We also believe that these changes are best developed in direct concert with the upstream software communities whose work is part of the Fedora distribution. We work with the upstream in cases where we find opportunities for improvement, so all free software users benefit — even if they don’t use Fedora directly.
## My verdict
I don't see any of both reflected in the current implementation of the new Cockpit Fileshare Plugin.
Instead, it is tried to implement a vendor specific addition to Fedora, that is neither related to Cockpit nor to Fedora and where (as far as I can see) the vendor is not even interested in Fedora:
https://github.com/45Drives/cockpit-file-sharing/issues/8
Therefore the Fedora Team has to prepared for issues like:
- My existing Samba configuration is not shown - How do I migrate from either config way to the other? - I installed it and now my data in /var/lib/xxx is not working anymore - I cannot write /etc/exports - Stuff in /etc/exports.d/ is not detected properly
Chances are high that users will install the plugin and expect "it just works". The discussion in this thread alone is showing, that this is not the case.
Getting in touch with the upstream (45Drives and Cockpit) and find a way to solve these issues or provide downstream patches and documentation seems to be necessary.
Best regards, Daniel --- ### Contact
dschier@while-true-do.io dschier @libera.chat linkedin.com/u/dschier twitter.com/dschier_wtd norden.social/@dschier github.com/dschier-wtd/
### Projects
while-true-do.io style-cheat.io
### Disclaimer
If not stated otherwise all of my work is licensed under a Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/).
On Do, Apr 14 2022 at 18:04:45 -0400, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Apr 14, 2022 at 07:29:48AM +0300, Alexander Bokovoy wrote:
I understand what you have proposed. I have pointed that it is not possible because not everything can be overridden from such config and, sadly, those bits are what common to all configurations. Content in /var/lib/samba is what matters, not where config file is located.
I think in the overwhelming number of cases I care about, samba will not have any previous configuration. I would be perfectly fine with the plugin recognizing anything other than:
- whatever is the default out of the box
- its own configuration
... and then displaying something like "This system has already been configured for advanced file sharing. It can't be managed via this interface. If this isn't what you want, remove all existing configuration and return here."
-- Matthew Miller <mattdm@fedoraproject.org mailto:mattdm@fedoraproject.org> Fedora Project Leader _______________________________________________ server mailing list -- server@lists.fedoraproject.org mailto:server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org mailto:server-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On pe, 15 huhti 2022, Daniel Schier wrote:
Hello all,
you can ignore everything below, since I am neither a software maintainer for Fedora nor Developer of Cockpit. Therefore, let me thank you for the awesome work you are doing and the value you are adding.
I was following the whole discussion of Cockpit-Samba/NFS integration. From my perspective, it is a nice feature to have (in the future) and maybe even a cool use case for some users. Nevertheless, we have to keep in mind, that there are some very prominent statements in the room for both, Fedora and Cockpit, that will be taken as a promise from users:
## From the Cockpit Project Landing Page:
Cockpit uses APIs that already exist on the system. It doesn’t reinvent subsystems or add a layer of its own tooling.
This cockpit app uses APIs that already exist on the system. It relies on the ability to programmatically set Samba configuration entries with 'net conf' for Samba configuration registry backend. There is nothing wrong with it.
## From the Fedora Foundations (Features):
We also believe that these changes are best developed in direct concert with the upstream software communities whose work is part of the Fedora distribution. We work with the upstream in cases where we find opportunities for improvement, so all free software users benefit — even if they don’t use Fedora directly.
## My verdict
I don't see any of both reflected in the current implementation of the new Cockpit Fileshare Plugin.
Instead, it is tried to implement a vendor specific addition to Fedora, that is neither related to Cockpit nor to Fedora and where (as far as I can see) the vendor is not even interested in Fedora:
I think this upstream ticket was raised before we started this effort on Fedora Server integration of the app.
Therefore the Fedora Team has to prepared for issues like:
- My existing Samba configuration is not shown
- How do I migrate from either config way to the other?
- I installed it and now my data in /var/lib/xxx is not working anymore
- I cannot write /etc/exports
- Stuff in /etc/exports.d/ is not detected properly
Chances are high that users will install the plugin and expect "it just works". The discussion in this thread alone is showing, that this is not the case.
Getting in touch with the upstream (45Drives and Cockpit) and find a way to solve these issues or provide downstream patches and documentation seems to be necessary.
Yes, this is a line of action I'd been pointing to in my responses as well.
On to, 14 huhti 2022, Matthew Miller wrote:
On Thu, Apr 14, 2022 at 07:29:48AM +0300, Alexander Bokovoy wrote:
I understand what you have proposed. I have pointed that it is not possible because not everything can be overridden from such config and, sadly, those bits are what common to all configurations. Content in /var/lib/samba is what matters, not where config file is located.
I think in the overwhelming number of cases I care about, samba will not have any previous configuration. I would be perfectly fine with the plugin recognizing anything other than:
- whatever is the default out of the box
- its own configuration
... and then displaying something like "This system has already been configured for advanced file sharing. It can't be managed via this interface. If this isn't what you want, remove all existing configuration and return here."
There are no sane ways of detecting whether configuration is default or not.
Sure, you can detect whether registry backend is enabled. You can also detect a role Samba runs in and refuse operating on unsupported roles. I think that's at most what could be done.
There is not even a way to find out whether your current config backend is registry. In FreeIPA case we use the following smb.conf:
# cat /etc/samba/smb.conf ### Added by IPA Installer ### # DO NOT EDIT # [global] debug pid = yes state directory = /var/lib/samba cache directory = /var/lib/samba include = registry
and if you would compare output of the `testparm -s -v` between this and a normal Samba setup, you'd see only difference in the role but not the config backend:
# testparm -s -v 2>&1 |egrep '(Server role|config backend)' Server role: ROLE_IPA_DC config backend = file
# testparm -s -v 2>&1 |egrep '(Server role|config backend)' Server role: ROLE_STANDALONE config backend = file
testparm simply does not see 'include = registry' individually as Samba parser consumes that:
# testparm -s -v 2>&1 |egrep '(Server role|include)' Server role: ROLE_IPA_DC include system krb5 conf = Yes include =
So in order to distinguish the cases we would need to apply some other logic.
I am fine if Cockpit app would limit itself to the cases it considers supportable. However, at the moment I don't see a good way to detect what is supportable purely from the configuration file using Samba tools.
On Fri, Apr 15, 2022 at 08:21:09AM +0300, Alexander Bokovoy wrote:
I am fine if Cockpit app would limit itself to the cases it considers supportable. However, at the moment I don't see a good way to detect what is supportable purely from the configuration file using Samba tools.
What about (warning: untested bash I'm writing ad-hoc!) something like:
if ! rpmverify -c samba-common; then if [[ -h /etc/samba/smb.conf ]] && [[ "$(readlink /etc/samba/smb.conf)" ]] == "/usr/share/cockpit/file-sharing/samba-manager/config/smb.conf"]; then echo "Already configured for cockpit module." else echo "System is configured in some other way. We can't handle this. Read more..." fi else echo "Default config detected. Press this button to activate cockpit module config." fi
On su, 17 huhti 2022, Matthew Miller wrote:
On Fri, Apr 15, 2022 at 08:21:09AM +0300, Alexander Bokovoy wrote:
I am fine if Cockpit app would limit itself to the cases it considers supportable. However, at the moment I don't see a good way to detect what is supportable purely from the configuration file using Samba tools.
What about (warning: untested bash I'm writing ad-hoc!) something like:
if ! rpmverify -c samba-common; then if [[ -h /etc/samba/smb.conf ]] && [[ "$(readlink /etc/samba/smb.conf)" ]] == "/usr/share/cockpit/file-sharing/samba-manager/config/smb.conf"]; then echo "Already configured for cockpit module." else echo "System is configured in some other way. We can't handle this. Read more..." fi else echo "Default config detected. Press this button to activate cockpit module config." fi
Probably something of that, right. It probably would be good to add more explanation into the final 'else' block what it does mean by 'activate cockpit module config' too. I guess we can add a wiki page and specify URL to it.
Am 13.04.2022 um 19:41 schrieb Alexander Bokovoy abbra@fedoraproject.org:
he 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.
Excuse my possible lack of knowledge, but I'm wondering about that. I think, we are basically discussing servers here. And the Cockpit file sharing app is meant to make management of shares on the server easier. Nothing else.
Or what did I get wrong?
On ke, 13 huhti 2022, Peter Boy wrote:
Am 13.04.2022 um 19:41 schrieb Alexander Bokovoy abbra@fedoraproject.org:
he 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.
Excuse my possible lack of knowledge, but I'm wondering about that. I think, we are basically discussing servers here. And the Cockpit file sharing app is meant to make management of shares on the server easier. Nothing else.
Or what did I get wrong?
Yes, I believe we are looking here from different perspectives. You are talking about a purpose-built deployment. I am talking about Fedora perspective.
For Fedora as a distribution there are no differences in what packages used in which deployments. They all are part of the same repository. The fact that a particular package may be a part of Fedora Server installation image is irrelevant: a user may install the very same package onto Fedora Workstation after deployment with the same ease of use as Fedora Server's user can install Gnome packages onto Fedora server deployed using Fedora Server image.
Nothing in the package itself earmarks it for a particular use. I gave earlier an example of Fedora Accounts system. I have seen this multiple times: a person wants to install FreeIPA server and thus uses
dnf install freeipa-*
this will bring 'freeipa-fas' to the system as well. Fedora Accounts packages are part of Fedora, installing freeipa-fas will reconfigure your FreeIPA server to do a particular job for Fedora Accounts. This package is not compatible with a normal FreeIPA server deployment in a sense that it provides a default configuration for Fedora Accounts that is not necessary what you'd want to use for normal FreeIPA. It, for example, forces use of OTP tokens by default. Due to how FreeIPA server upgrade runs, settings like enforced by freeipa-fas package will revert any other changes done in the same area. So you'd end up with a misterious behaviour: your FreeIPA configuration suddenly resets to something that you did not recognize.
This cockpit plugin could be installed onto any Fedora deployment. Many people reported us bugs with file sharing when sharing their own home directories or directories from their Fedora workstations. This is why I mentioned Fedora Workstation is one actual target for this -- because people do use Samba file sharing on their workstations.
For me a time to investigate bugs where things happen due to behaviours like this is a time taken away from serving actual causes for Fedora users who actually care about their Samba setups.
On Wed, Apr 13, 2022 at 07:47:23AM +0300, Alexander Bokovoy wrote:
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.
I'm not suggesting doing it unconditionally, but I think it should be done with as little bothering-the-user as possible _when the samba package is installed via the plugin._ And I'd like it to be that easy in other cases as well. A wizard that walks people through what you're saying are possibly complicated and dangerous steps doesn't seem like good UX for the user profiles we've identified for Fedora Server.
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.
I agree that we should avoid a scenario where there is an existing samba setup, and simply installing the plugin makes a gigantic change.
On to, 14 huhti 2022, Matthew Miller wrote:
On Wed, Apr 13, 2022 at 07:47:23AM +0300, Alexander Bokovoy wrote:
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.
I'm not suggesting doing it unconditionally, but I think it should be done with as little bothering-the-user as possible _when the samba package is installed via the plugin._ And I'd like it to be that easy in other cases as well. A wizard that walks people through what you're saying are possibly complicated and dangerous steps doesn't seem like good UX for the user profiles we've identified for Fedora Server.
I do not see how you can detect whether Samba package was installed via the plugin. Can you please provide more details on how you plan to provide that?
I don't want you to create a big wizard. I think we both agree the App should detect whether current configuration is supported or could be supported and that be it.
Perhaps we can try to have the discussion of further development from a different perspective? Namely, what do we want to achieve and what means can we use? (Instead of what is not possible)
Originally, we wanted to make it easier for the Sysadmin to manage Samba shares, that is create, delete, modify shares, and add, remove, modify permissions of users. And we want to do it on servers, not any server, but =Fedora Server Edition=. nothing else. It was inspired by specific user questions, if I remember correctly.
And we want to use Fedora packages, which have a broader perspective, of course. So we may add a "Fedora Server Samba config package“ which tailors the broader perspective to Fedora Server Edition? Maybe not a rpm, but set of stop-by-step doc, Ansible playbook, or a shell script.
As Server Edition we have an idea, how to use and manage various services and how a service fits best into Fedora Server Edition infrastructure (e.g. we write about how to add virtualization and use postgres database, both much simpler as Samba, just an example of the idea).
So we can add docs "Installing and Configuring Samba on Fedora Server Edition“ and create a configuration template that works and that does not cause a lot of questions or bug reports. And fit file sharing module into it. (I wrote once such a guide decades ago at the time of Fedora Core something. A lot has changed, but in principle this should be possible today as well). At the end we may have an Ansible script that does the work.
Not very specific so far, but maybe we should start with a use case?
On pe, 15 huhti 2022, Peter Boy wrote:
Perhaps we can try to have the discussion of further development from a different perspective? Namely, what do we want to achieve and what means can we use? (Instead of what is not possible)
Originally, we wanted to make it easier for the Sysadmin to manage Samba shares, that is create, delete, modify shares, and add, remove, modify permissions of users. And we want to do it on servers, not any server, but =Fedora Server Edition=. nothing else. It was inspired by specific user questions, if I remember correctly.
And we want to use Fedora packages, which have a broader perspective, of course. So we may add a "Fedora Server Samba config package“ which tailors the broader perspective to Fedora Server Edition? Maybe not a rpm, but set of stop-by-step doc, Ansible playbook, or a shell script.
As Server Edition we have an idea, how to use and manage various services and how a service fits best into Fedora Server Edition infrastructure (e.g. we write about how to add virtualization and use postgres database, both much simpler as Samba, just an example of the idea).
So we can add docs "Installing and Configuring Samba on Fedora Server Edition“ and create a configuration template that works and that does not cause a lot of questions or bug reports. And fit file sharing module into it. (I wrote once such a guide decades ago at the time of Fedora Core something. A lot has changed, but in principle this should be possible today as well). At the end we may have an Ansible script that does the work.
Not very specific so far, but maybe we should start with a use case?
To me Fedora Server Edition does not exist independently of the Fedora itself. A part of the work to improve server user experience in Fedora, I consider collaboration with upstream projects that we package and represent in Fedora. If there is no collaboration, it is hard to influence changes that are required to achieve better user experience or move forward to implement specific features needed for the distribution.
It is what makes Fedora a best distribution to run FreeIPA, for example, as we continuously reassess both Fedora and RHEL needs, reflect them in requirements towards upstream projects (not just FreeIPA, there are about dozen projects we have to actively work with to make it all happen), come to upstream with proposals and implementations of those proposals and so on.
I do not think claiming that a particular package is only supported within Fedora Server Edition is a sound approach. Sure, you can do that, and I would probably be the last one who would stop you from that. I am more concerned with the resulting drain of my time as an official package maintainer (for samba, freeipa, sssd, krb5, etc.) when dealing with bugs I cannot solve for the users who reported them. I feel sorry for those users for not being able to help them.
For Samba and file systems we already have comprehensive materials in RHEL documentation. They were developed together with RHEL engineers and upstream contributors. Samba documents, for example, were written by Marc Muehlfeld who is documentation writer at Red Hat but also a Samba Team member and wrote a lot of documentation on wiki.samba.org.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-bet...
I am not sure how these can be pulled into Fedora documentation, though.
server@lists.fedoraproject.org
-
Alexander Bokovoy -
Daniel Schier -
Martin Pitt -
Matthew Miller -
Peter Boy -
Simo Sorce -
Stephen Gallagher