On Thu, 12 Apr 2018 21:19:52 +0200 Per Jessen <per@computer.org> wrote:
On 12/04/18 09:39, Michal Suchánek wrote:
On Wed, 11 Apr 2018 18:25:59 +0200 Per Jessen <per@computer.org> wrote:
Frederic Crozat wrote:
Le mardi 10 avril 2018 à 13:04 +0200, Michal Kubecek a écrit :
On Tuesday, 10 April 2018 12:16 Richard Brown wrote:
I would like to propose that the installation options KDE and GNOME therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
I don't see much benefit of NetworkManager on a typical desktop machine.
Proper integration in the desktop of VPN start / stop.
Perhaps not of great use to the average desktop user, but yes. How about NFS-mounted shares - last I looked (42.3), it took some work to get those integrated.
Net mounted filesystems don't work with systemd and we are using systemd so you are out of luck here. Get an Evergreen distro for that.
Dear Michal
We're using systemd, NFS mounted shares work quite well.
Dear Per, I am using iSCSI root and it does not work with systemd. From what I heard people using network filesystems for filesystems required by system services have same issues. This is not SUSE problem. This is problem of systemd in any distribution. One thing is that systemd does not have a notion of network service connectivity (ie. ability to reach the server that provides your filesystem). It has only network up and network down. Even in absence of proper network service dependencies you can mark filesystem in fstab as "network" which is supposed to make it depend on network and prevent systemd from shutting down network while the filesystem is mounted. This does not work. If the filesystem is used by system service unmounting the filesystem times out but the network is shut down nonetheless. It would be much simpler if systemd did not shut down the network at all. Why bother if the system is shut down anyway. Nonetheless it insists and this leads to numerous bugs and in general inability to shut down systems that rely on network filesystems. Finally the systemd project is really bad with documentation. It uses some kind of object system to represent services, targets, and whatever else there is to enable or disable. Unfortunately, the man page for service would only describe the properties specific to the service object and would not include description of the base object or even clear reference to that description. So wherever you look you see only a fragment of the documentation that is quite useless by itself. Quite stark contrast to sysvinit scripts which were written in shell language which has complete reference, tutorials, etc. Also in contrast to sysvinit service files where you had to explicitly source each configuration file and script providing utility functions the systemd services are composed of multiple files spread across different places on the filesystem without any clear connection (ie. service redefinition and override files). Again there might be some place in the systemd documentation where detailed description of this is available but it is not described in the man page which describes a service file. While the documentation is poor it could be saved by distributions adopting systemd providing resources for package maintainers so they can create nice, clean and properly working systemd service files that can serve as examples to others. Alas, distributions including openSUSE ship broken systemd service files which are written without knowledge of systemd design, solve problems in awkward ways and in many cases don't work at all. These then serve as examples to others and the wrong knowledge is perpetuated indefinitely. This documentation problem probably applies to managing systems that use network dependent filesystems as well. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org