Comparison to Workstation Technical Specification

[Stephen Gallagher]

So, the Workstation group has done a truly fantastic job these last
couple of weeks designing their Technical Specification[1]. At today's
Server WG meeting, the topic came up about the "Core Services and
Features" section of this document. I think that much of it is reusable
for the Server Technical Specification, so I'm going to go through it
and make comments and recommendations. Please add your own thoughts and
I'll get them up on the wiki tomorrow.


> === File system ===
>
> The default file system type for workstation installs should be
> btrfs.

The default file system is definitely up for some debate, but I'd make
an argument for using XFS atop LVM[1] for the default filesystem in
the Fedora Server, at least in part because Red Hat's storage experts
have done the research for us already and determined that XFS is the
recommended fit for Red Hat Enterprise Linux 7.

Btrfs still makes me somewhat nervous, given that its upstream doesn't
consider it stable[3].



>
> === Service management ===
>
> Systemd provides ways to control and monitor the activity and
> status of system services, resources they require, etc. System
> services are expected to provide systemd units. See the systemd
> [http://0pointer.de/public/systemd-man/systemd.unit.html
> documentation].
>


I think we want to go along with this, but make a stronger statement
about systemd units.

"System services *must* provide systemd units to be included in the
Fedora Server standard installation."



> === Logging ===
>
> The systemd journal will be used as the local storage backend for
> system logs. For 'managed' scenarios (e.g the 'developer in a
> large organization' use case of the PRD), it will be possible to
> collect the logs in a centralized location, off the local machine.
>
> Applications and services can either use the syslog API or the
> journal APIs for their logging. See the journal API
> [http://0pointer.de/public/systemd-man/sd-journal.html
> documentation].
>


I agree with this as well. We should focus on the use of journald as
the preferred log aggregator and make sure that it is fully capable of
aggregating those logs centrally. The advantages provided by
journald's structured logging will make processing of those logs much
easier.

That said, for the immediate future I think we also need to mandate
that the system MUST continue to be capable of exporting traditional
syslog messages to existing log aggregation systems.


> === Networking ===
>
> Network devices and connections will be controlled by
> NetworkManager. This includes support for VPN, which is relevant
> for 'corporate' scenarios. Applications are advised to use
> higher-level APIs (such as
> [https://developer.gnome.org/gio/stable/GNetworkMonitor.html
> GNetworkMonitor] in GIO) to monitor online status.
>


This is going to be the contentious point, I expect. We've already
seen some chatter on this list around systemd-networkd and of course
there's a long history of wariness around NetworkManager as a
replacement for traditional network scripts.

This will need to come to a vote, but here are my feelings on the matter:

== Network Scripts ==
+ Powerful, stable and widely deployed.
- Configuration requires modification of a large number of plaintext
files. Central management of this configuration is difficult and
generally requires tools like Puppet and Chef to be deployed to do
so reliably.
- Complex configuration is highly prone to accidents necessitating a
visit from the "crash cart" in the data center.

== Network Manager ==
+ Powerful and (now) stable with support for enterprise features like
bridging and bonding.
+ Consistent API allows for simplified configuration with fewer
opportunities for producing an unusable system.
+ Default networking stack for RHEL 7 means it will get considerable
bugfixing resources allocated to it.
- Requires a running daemon on the system (though work is under way to
have the daemon shut down except when needed)
- Bad PR history means that some administrators view it unfavorably

== systemd-networkd ==
+ Very low overhead, tight integration with low-level plumbing
- Immature with few features. Only saw its first release this month.
- Not currently available on Fedora[4]


My personal view is that NetworkManager is the best option *today*
(understanding full well that there will need to be a fair amount of
marketing effort to educate people on how far it has come in the last
couple years), while systemd-networkd may become a highly interesting
option in the future. Given our focus in Fedora Server on making
configuration more approachable, I can't really see us recommending
network scripts as the *default* offering.


> === Firewall ===
>
> A firewall in its default configuration may not interfere with the
> normal operation of programs installed by default.


I would extend this statement to include that the deployment of Server
Roles should also adjust the firewall operation in a manner consistent
with user expectation.


> We should detect when the system is on a public or untrusted
> network and prevent the user from unwanted sharing of e.g. music or
> other media in this situation. A firewall (and network zones as
> currently implemented by firewalld) may or may not be part of a
> solution to this.
>

The concept of network zones should probably be basically ignored for
Fedora Server, as we should generally default to closing all ports
except for those made available for installed Roles. (Also, the Role
configuration should optionally be able to specify on which interfaces
it wishes to operate, so we can restrict internal vs. external
operation in a multi-homed environment).


> === SELinux ===
>
> SELinux will be enabled in enforcing mode, using the targeted
> policy.
>

+1000

The base install and all approved Server Roles must operate in
targeted enforcing mode.


> === Problem reporting ===
>
> Problems and error conditions (e.g. kernel oopses, Selinux AVCs,
> application crashes, OOM, disk errors) should all be reported in
> the systemd journal.

Ack


> Sending this information to a central place (like abrt does for
> crashes today) should be possible, but not mandatory. Depending on
> the use case, it may be turned off, enabled manually on a
> case-by-case basis, or entirely automatic without user
> intervention.
>


In the case of the Fedora Server, I think that reporting information
to a central location must be mandatory. Most servers in real-world
deployment are headless in a datacenter somewhere. Administrators will
need to be able to see all issues from a standard console.

Also, we need to keep in mind that the majority of servers will *not*
have visibility to the internet, so transmitting ABRT results directly
to Bugzilla is often impossible. We will need to be able to aggregate
the issues on a network-local management server. (Note: IMHO this is
not a blocker requirement on F21)


> === Session tracking ===
>
> Logind will be used as the session tracking facility.
>
> Applications that need to interact with sessions can use the
> logind
> [http://www.freedesktop.org/software/systemd/man/sd_session_is_active.html
>
>
library API], the
> [http://www.freedesktop.org/wiki/Software/systemd/logind/ D-Bus
> API], or a higher-level API
>


+1


> === Account handling ===
>
> SSSD is providing the backing storage for identity management. For
> 'managed' scenarios (e.g. the 'developer in a large organization'
> use case of the PRD), it will be possible to configure it to rely
> on a directory service for this information. The accountsservice
> is providing a D-Bus interface for user account information; this
> may be integrated into SSSD at some point.
>
> Depending on their needs, application and services can either use
> the POSIX APIs (getpwent(), etc) or the accountsservice D-Bus
> interface to obtain user information.
>


As the Fedora Server is more likely than Workstation to require
central management, I think we need to adopt this wholeheartedly.
Also, realmd should be considered a core piece of our story, as it
enables automatic configuration of SSSD with either FreeIPA (our
Domain Controller Role) or Active Directory (Microsoft Windows Domain
Controller).



> === Software updates ===
>
> gnome-software will use PackageKit with the hawkey backend to
> obtain and install software updates for packaged applications and
> the OS itself. The recommendation for applications is to use the
> PackageKit APIs to interact with the underlying packaging system.
>


Software updates on a server system should be designed in such a way
that they can be enforced centrally. With Fedora Server, this probably
means picking one of the common config management systems such as
Puppet, Chef, Red Hat Satellite or else relying on OpenLMI for
performing central software upgrades.

For single-server manipulation, I think we should focus on supporting
yum/dnf.


> === Miscellaneous system information ===
>
> System locale, timezone, hostname, etc. will be managed through
> the services provided by systemd for this purpose. See developer
> documentation for
> [http://www.freedesktop.org/wiki/Software/systemd/localed/
> localed],
> [http://www.freedesktop.org/wiki/Software/systemd/timedated/
> timedated] and
> [http://www.freedesktop.org/wiki/Software/systemd/hostnamed/
> hostnamed]
>


I also think we should stick with the systemd-offered mechanisms for
this functionality (and I know that Cockpit is already interfacing
with much of it).


> === Virtualization ===
>
> libvirt-daemon will be used to manage virtualization capabilities.
>


We probably want to use libvirt-daemon for virtualization and focus on
systemd-nspawn for containerization.


> === Display manager ===
>
> gdm will be used as the display manager. It is responsible for
> showing a login screen on each seat. It will be able to launch
> both X-based sessions and Wayland sessions.
>
> Desktop environments are expected to make themselves known as an
> available session option on the login screen by dropping a
> .desktop file into /usr/share/xsessions (or its wayland
> equivalent).
>
> Other facilities provided by the display manager include screen
> unlock authentication and user switching.
>


Display manager is irrelevant to the Server product.


> === Accessibility ===
>
> The accessibility support in the workstation includes a screen
> reader, a high-contrast theme and a zoom capability, amongst
> others. The screen reading is provided through orca, which runs as
> a session service and requires the at-spi infrastructure.
> Applications are expected to provide suitable information to the
> screen reader via the toolkit's accessibility support. Applications
> are also expected to work acceptably in the high-contrast theme.
> The zoom is implemented in the desktop shell and does not need any
> application support.
>


Accessibility on the server is a topic I'm fairly comfortable with
deferring to the management tools such as Cockpit and Katello/Foreman.
On the pure command-line, I think the most we can do is assert that
any interactive operation we enable should have a configurable timeout
to deal with potentially slow typists.


> === Input Methods ===
>
> The input method framework on the workstation is provided by ibus.
> Input methods and keyboard layouts can be configured in the
> control-center, and selected in shell keyboard menu. The supported
> application toolkits all support ibus.
>


I'm not sure this is a situation we need to get ourselves involved in.
Most interaction will be in the shell, so hopefully the LOCALE setting
will be sufficient.


> === Graphics ===
>
> The workstation session will switch to using a Wayland compositor
> as soon as feasible. Until then, it will be based on X11. Even
> after the switch, an X server will be included, so applications can
> either connect to Wayland natively, or run as an X client.
>


Not applicable


> === Media support ===
>
> Sound hardware and audio streams will be managed by pulseaudio.
> Applications are recommended to use the
> [http://gstreamer.freedesktop.org/documentation/ gstreamer]
> framework for media playback.
>


Not applicable


> === Appearance ===
>
> The workstation will ship with a single theme, which will have
> support for the included toolkits: gtk3, qt and gtk2. Applications
> are expected to work well with this theme, as well as with the
> high-contrast theme that is used for accessibility. The theme will
> include a dark variant that applications can opt into using (this
> is most suitable for certain content-focused applications). The
> theme also includes an icon theme that provides named icons
> according to the icon-naming spec, plus symbolic variants.
>
> We will be using the Adwaita theme, with a yet-to-be-written qt
> variant.
>


As for "appearance", my view is that Cockpit should be the official
"face" of the Fedora Server. Opinions welcome :)



> === Application Integration ===
>
> Installed applications are expected to install a desktop file in
> /usr/share/applications and an application icon in the hicolor
> icon theme.
>
> Packaged applications are also expected to provide
> [http://people.freedesktop.org/~hughsient/appdata/ appdata] for
> use in the application installer.
>


Not applicable


> === System Installer ===
>
> The desired installation experience for the workstation product is
> to limit the pre-installation user interaction to the minimum. The
> storage configuration UI should be focused on the classes of
> hardware that are expected in workstation-class machines. Package
> selection is not necessary: the installer will install the
> workstation product as defined. Tweaks, customizations and software
> additions should be performed after the installation.
>
> One aspect of storage configuration that will be needed is support
> for dual-boot setups (preserving preexisting Windows or OS X
> installations), since e.g. students may be required to run
> software on those platforms for their coursework.
>
> gnome-initial-setup already provides support for post-install user
> creation, language selection, timezone configuration, etc. If
> necessary, it should be extended to cover all required setup
> tasks.


I'm not even sure where to begin here. The system installer discussion
probably needs to have its own thread.






[1] https://fedoraproject.org/wiki/Workstation/Technical_Specification

[2] I haven't got an opinion on traditional LVM vs. thinly-provisioned
LVM at this point.

[3] https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F

[4]
http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html

[Bill Nottingham]

Stephen Gallagher (sgallagh at redhat.com) said:
> > === Display manager ===
> >
> > gdm will be used as the display manager. It is responsible for
> > showing a login screen on each seat. It will be able to launch
> > both X-based sessions and Wayland sessions.
> >
> > Desktop environments are expected to make themselves known as an
> > available session option on the login screen by dropping a
> > .desktop file into /usr/share/xsessions (or its wayland
> > equivalent).
> >
> > Other facilities provided by the display manager include screen
> > unlock authentication and user switching.
> >
>
>
> Display manager is irrelevant to the Server product.

Admittedly, this is rehashing a bit of an old discussion, but we have
(RHEL) stats that somewhere around 20% of server installs install a desktop.

If Fedora Server wants to explicitly not serve those users, it's worth
noting specifically. If it wants to serve them by offering some sort of
environment that boots into just cockpit + terminal + web browser, it's
worth specifying the requirements there.

Bill

[Stephen Gallagher]

On 02/25/2014 03:58 PM, Bill Nottingham wrote:
> Stephen Gallagher (sgallagh at redhat.com) said:
>>> === Display manager ===
>>>
>>> gdm will be used as the display manager. It is responsible for
>>> showing a login screen on each seat. It will be able to
>>> launch both X-based sessions and Wayland sessions.
>>>
>>> Desktop environments are expected to make themselves known as
>>> an available session option on the login screen by dropping a
>>> .desktop file into /usr/share/xsessions (or its wayland
>>> equivalent).
>>>
>>> Other facilities provided by the display manager include screen
>>> unlock authentication and user switching.
>>>
>>
>>
>> Display manager is irrelevant to the Server product.
>
> Admittedly, this is rehashing a bit of an old discussion, but we
> have (RHEL) stats that somewhere around 20% of server installs
> install a desktop.
>
> If Fedora Server wants to explicitly not serve those users, it's
> worth noting specifically. If it wants to serve them by offering
> some sort of environment that boots into just cockpit + terminal +
> web browser, it's worth specifying the requirements there.
>

"7. The user must be able to install and manage Fedora Server in a
headless mode where the display framework is inactive." [1]


That being said, Cockpit itself has a terminal emulator built-in as
well. So ideally there's no reason to install a graphical environment
on the system. You should be able to just connect to it from any
browser and operate from there.


Also, I want to make it relatively easy for a Fedora Server install to
also essentially just "push a button" and also have a fully-functional
Workstation. That should be a non-default case.



[1]
https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Use_Cases

[Simo Sorce]

On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So, the Workstation group has done a truly fantastic job these last
> couple of weeks designing their Technical Specification[1]. At today's
> Server WG meeting, the topic came up about the "Core Services and
> Features" section of this document. I think that much of it is reusable
> for the Server Technical Specification, so I'm going to go through it
> and make comments and recommendations. Please add your own thoughts and
> I'll get them up on the wiki tomorrow.
>
>
> > === File system ===
> >
> > The default file system type for workstation installs should be
> > btrfs.

UGH! Certainly not on my hardware, hopefully this will be easy to
change.

> The default file system is definitely up for some debate, but I'd make
> an argument for using XFS atop LVM[1] for the default filesystem in
> the Fedora Server, at least in part because Red Hat's storage experts
> have done the research for us already and determined that XFS is the
> recommended fit for Red Hat Enterprise Linux 7.

Even if it weren't the default on RHEL7 I would second using XFS, it's
defeinitely the best Server File System we have available right now,
when you weight size/features/reliability

> Btrfs still makes me somewhat nervous, given that its upstream doesn't
> consider it stable[3].

It is not stable yet, I do not think it makes sense for us to go btrfs
for a server. A desktop may get away with (although the one laptop where
I have it for testing sure would like to have something that is not that
slow)

> > === Service management ===
> >
> > Systemd provides ways to control and monitor the activity and
> > status of system services, resources they require, etc. System
> > services are expected to provide systemd units. See the systemd
> > [http://0pointer.de/public/systemd-man/systemd.unit.html
> > documentation].
> >
> I think we want to go along with this, but make a stronger statement
> about systemd units.
>
> "System services *must* provide systemd units to be included in the
> Fedora Server standard installation."

I think this is a given, but if we feel the need to spell it out let's
do it.

> > === Logging ===
> >
> > The systemd journal will be used as the local storage backend for
> > system logs. For 'managed' scenarios (e.g the 'developer in a
> > large organization' use case of the PRD), it will be possible to
> > collect the logs in a centralized location, off the local machine.
> >
> > Applications and services can either use the syslog API or the
> > journal APIs for their logging. See the journal API
> > [http://0pointer.de/public/systemd-man/sd-journal.html
> > documentation].
> >
>
>
> I agree with this as well. We should focus on the use of journald as
> the preferred log aggregator and make sure that it is fully capable of
> aggregating those logs centrally. The advantages provided by
> journald's structured logging will make processing of those logs much
> easier.
>
> That said, for the immediate future I think we also need to mandate
> that the system MUST continue to be capable of exporting traditional
> syslog messages to existing log aggregation systems.

I agree I think we MUST support full log aggregation via rsyslog, and
possibly make it easy to activate it.

> > === Networking ===
> >
> > Network devices and connections will be controlled by
> > NetworkManager. This includes support for VPN, which is relevant
> > for 'corporate' scenarios. Applications are advised to use
> > higher-level APIs (such as
> > [https://developer.gnome.org/gio/stable/GNetworkMonitor.html
> > GNetworkMonitor] in GIO) to monitor online status.
> >
>
>
> This is going to be the contentious point, I expect. We've already
> seen some chatter on this list around systemd-networkd and of course
> there's a long history of wariness around NetworkManager as a
> replacement for traditional network scripts.
>
> This will need to come to a vote, but here are my feelings on the matter:
>
> == Network Scripts ==
> + Powerful, stable and widely deployed.
> - Configuration requires modification of a large number of plaintext
> files. Central management of this configuration is difficult and
> generally requires tools like Puppet and Chef to be deployed to do
> so reliably.
> - Complex configuration is highly prone to accidents necessitating a
> visit from the "crash cart" in the data center.

I think we should stop with scripts in Fedora Server, they are brittle.

> == Network Manager ==
> + Powerful and (now) stable with support for enterprise features like
> bridging and bonding.
> + Consistent API allows for simplified configuration with fewer
> opportunities for producing an unusable system.
> + Default networking stack for RHEL 7 means it will get considerable
> bugfixing resources allocated to it.
> - Requires a running daemon on the system (though work is under way to
> have the daemon shut down except when needed)
> - Bad PR history means that some administrators view it unfavorably

+1

> == systemd-networkd ==
> + Very low overhead, tight integration with low-level plumbing
> - Immature with few features. Only saw its first release this month.
> - Not currently available on Fedora[4]

-1 on immature grounds in the short term

> My personal view is that NetworkManager is the best option *today*
> (understanding full well that there will need to be a fair amount of
> marketing effort to educate people on how far it has come in the last
> couple years), while systemd-networkd may become a highly interesting
> option in the future. Given our focus in Fedora Server on making
> configuration more approachable, I can't really see us recommending
> network scripts as the *default* offering.

ack

> > === Firewall ===
> >
> > A firewall in its default configuration may not interfere with the
> > normal operation of programs installed by default.

I do not understand what "normal operation" means here.
What is normal is in part determined by what the user of the system
wants to accomplish.

> I would extend this statement to include that the deployment of Server
> Roles should also adjust the firewall operation in a manner consistent
> with user expectation.

Are we going to use something like firewalld or something else ?
Should we have the firewall configured by default, or not ?

> > We should detect when the system is on a public or untrusted
> > network and prevent the user from unwanted sharing of e.g. music or
> > other media in this situation. A firewall (and network zones as
> > currently implemented by firewalld) may or may not be part of a
> > solution to this.
> >
>
> The concept of network zones should probably be basically ignored for
> Fedora Server, as we should generally default to closing all ports
> except for those made available for installed Roles. (Also, the Role
> configuration should optionally be able to specify on which interfaces
> it wishes to operate, so we can restrict internal vs. external
> operation in a multi-homed environment).

What do we gain from a firewall that any application can poke holes at ?
Can someone state the benefits, or a situation where the default
configuration would be safer with a firewall ?


> > === SELinux ===
> >
> > SELinux will be enabled in enforcing mode, using the targeted
> > policy.
> >
>
> +1000
>
> The base install and all approved Server Roles must operate in
> targeted enforcing mode.

+1

> > === Problem reporting ===
> >
> > Problems and error conditions (e.g. kernel oopses, Selinux AVCs,
> > application crashes, OOM, disk errors) should all be reported in
> > the systemd journal.
>
> Ack

Is there another place they may be reported to ?

> > Sending this information to a central place (like abrt does for
> > crashes today) should be possible, but not mandatory. Depending on
> > the use case, it may be turned off, enabled manually on a
> > case-by-case basis, or entirely automatic without user
> > intervention.
> >
>
>
> In the case of the Fedora Server, I think that reporting information
> to a central location must be mandatory. Most servers in real-world
> deployment are headless in a datacenter somewhere. Administrators will
> need to be able to see all issues from a standard console.

There is a problem with sending information from things like abrtd to a
central location by default, in that sensitive information may get
disclosed unless the log server is reached only through authenticated
and encrypted connections.
Ideally we have a way to signal the trustworthiness of the log and
change behavior accrodingly and automatically. Whether we can do this in
the short/medium term I do not know.

But technically rsyslog can secure connections and even do mutual
authentication as it supports both TLS and GSSAPI. I also discussed at
DevConf.cz with the rsyslog maintainer some secure store-and-forward
techniques to use with ephemeral encryption keys and such so it is an
option.

> Also, we need to keep in mind that the majority of servers will *not*
> have visibility to the internet, so transmitting ABRT results directly
> to Bugzilla is often impossible. We will need to be able to aggregate
> the issues on a network-local management server. (Note: IMHO this is
> not a blocker requirement on F21)

Whether it is "possible" or not automatic transmission is almost always
inappropriate IMO. Too much potentially sensitive info can be
transmitted with these kinds of reports, they have to be validated and
approved for transmission by an admin.

I think this should be an actual requirement for the Server platform.

> > === Session tracking ===
> >
> > Logind will be used as the session tracking facility.
> >
> > Applications that need to interact with sessions can use the
> > logind
> > [http://www.freedesktop.org/software/systemd/man/sd_session_is_active.html
> >
> >
> library API], the
> > [http://www.freedesktop.org/wiki/Software/systemd/logind/ D-Bus
> > API], or a higher-level API
> >
>
>
> +1
>
>
> > === Account handling ===
> >
> > SSSD is providing the backing storage for identity management. For
> > 'managed' scenarios (e.g. the 'developer in a large organization'
> > use case of the PRD), it will be possible to configure it to rely
> > on a directory service for this information. The accountsservice
> > is providing a D-Bus interface for user account information; this
> > may be integrated into SSSD at some point.
> >
> > Depending on their needs, application and services can either use
> > the POSIX APIs (getpwent(), etc) or the accountsservice D-Bus
> > interface to obtain user information.
> >
>
>
> As the Fedora Server is more likely than Workstation to require
> central management, I think we need to adopt this wholeheartedly.
> Also, realmd should be considered a core piece of our story, as it
> enables automatic configuration of SSSD with either FreeIPA (our
> Domain Controller Role) or Active Directory (Microsoft Windows Domain
> Controller).

+1 (though I have a conflict of interest here :-)

> > === Software updates ===
> >
> > gnome-software will use PackageKit with the hawkey backend to
> > obtain and install software updates for packaged applications and
> > the OS itself. The recommendation for applications is to use the
> > PackageKit APIs to interact with the underlying packaging system.
> >
>
>
> Software updates on a server system should be designed in such a way
> that they can be enforced centrally. With Fedora Server, this probably
> means picking one of the common config management systems such as
> Puppet, Chef, Red Hat Satellite or else relying on OpenLMI for
> performing central software upgrades.

I think you forgot spacewalk here.

> For single-server manipulation, I think we should focus on supporting
> yum/dnf.

I think yum/successor CLI tool should be the default here indeed.

> > === Miscellaneous system information ===
> >
> > System locale, timezone, hostname, etc. will be managed through
> > the services provided by systemd for this purpose. See developer
> > documentation for
> > [http://www.freedesktop.org/wiki/Software/systemd/localed/
> > localed],
> > [http://www.freedesktop.org/wiki/Software/systemd/timedated/
> > timedated] and
> > [http://www.freedesktop.org/wiki/Software/systemd/hostnamed/
> > hostnamed]
> >
>
>
> I also think we should stick with the systemd-offered mechanisms for
> this functionality (and I know that Cockpit is already interfacing
> with much of it).

To be honest I find hostnamed quite inadequate for a server case as it
introduced confusion in the naming and by default will mangle perfectly
valid fqdns that the admin want to assign to the machine.

I think we should carefully evaluate these mechanisms.

For example, messing up with the hostname often has annoying
consequences when a server is enrolled into a central identity
management system.


> > === Virtualization ===
> >
> > libvirt-daemon will be used to manage virtualization capabilities.
> >
>
>
> We probably want to use libvirt-daemon for virtualization and focus on
> systemd-nspawn for containerization.

what about libvirt-lxc/docker ?

> > === Display manager ===
> >
> > gdm will be used as the display manager. It is responsible for
> > showing a login screen on each seat. It will be able to launch
> > both X-based sessions and Wayland sessions.
> >
> > Desktop environments are expected to make themselves known as an
> > available session option on the login screen by dropping a
> > .desktop file into /usr/share/xsessions (or its wayland
> > equivalent).
> >
> > Other facilities provided by the display manager include screen
> > unlock authentication and user switching.
> >
>
>
> Display manager is irrelevant to the Server product.

We already discussed in some cases we will need them as some server
software unfortunately need a grpahical session for
installation/configuration purposes.

So we should have at least a recommendation of how to start a graphical
session if required, even if it is just a manual startx or if the
recommendation is to use Xvnc and a vnc client or other similar options.

> > === Accessibility ===
> >
> > The accessibility support in the workstation includes a screen
> > reader, a high-contrast theme and a zoom capability, amongst
> > others. The screen reading is provided through orca, which runs as
> > a session service and requires the at-spi infrastructure.
> > Applications are expected to provide suitable information to the
> > screen reader via the toolkit's accessibility support. Applications
> > are also expected to work acceptably in the high-contrast theme.
> > The zoom is implemented in the desktop shell and does not need any
> > application support.
> >
>
>
> Accessibility on the server is a topic I'm fairly comfortable with
> deferring to the management tools such as Cockpit and Katello/Foreman.
> On the pure command-line, I think the most we can do is assert that
> any interactive operation we enable should have a configurable timeout
> to deal with potentially slow typists.

We should at least support braille devices out of the box for console
interaction IMO.


> > === Input Methods ===
> >
> > The input method framework on the workstation is provided by ibus.
> > Input methods and keyboard layouts can be configured in the
> > control-center, and selected in shell keyboard menu. The supported
> > application toolkits all support ibus.
> >
>
>
> I'm not sure this is a situation we need to get ourselves involved in.
> Most interaction will be in the shell, so hopefully the LOCALE setting
> will be sufficient.
>
>
> > === Graphics ===
> >
> > The workstation session will switch to using a Wayland compositor
> > as soon as feasible. Until then, it will be based on X11. Even
> > after the switch, an X server will be included, so applications can
> > either connect to Wayland natively, or run as an X client.
> >
>
>
> Not applicable

See above.

> > === Media support ===
> >
> > Sound hardware and audio streams will be managed by pulseaudio.
> > Applications are recommended to use the
> > [http://gstreamer.freedesktop.org/documentation/ gstreamer]
> > framework for media playback.
> >
>
>
> Not applicable

There are server side media streamers, DLNA, etc.. we can defer taking
any action but it is incorrect to say that a server os has nothing to do
with media support.

> > === Appearance ===
> >
> > The workstation will ship with a single theme, which will have
> > support for the included toolkits: gtk3, qt and gtk2. Applications
> > are expected to work well with this theme, as well as with the
> > high-contrast theme that is used for accessibility. The theme will
> > include a dark variant that applications can opt into using (this
> > is most suitable for certain content-focused applications). The
> > theme also includes an icon theme that provides named icons
> > according to the icon-naming spec, plus symbolic variants.
> >
> > We will be using the Adwaita theme, with a yet-to-be-written qt
> > variant.
> >
>
>
> As for "appearance", my view is that Cockpit should be the official
> "face" of the Fedora Server. Opinions welcome :)

Should we say something about how the shell is configured, defaults,
bash-completion, vim-enhanced/emacs/other plugins ?

> > === Application Integration ===
> >
> > Installed applications are expected to install a desktop file in
> > /usr/share/applications and an application icon in the hicolor
> > icon theme.
> >
> > Packaged applications are also expected to provide
> > [http://people.freedesktop.org/~hughsient/appdata/ appdata] for
> > use in the application installer.
> >
>
>
> Not applicable
>
>
> > === System Installer ===
> >
> > The desired installation experience for the workstation product is
> > to limit the pre-installation user interaction to the minimum. The
> > storage configuration UI should be focused on the classes of
> > hardware that are expected in workstation-class machines. Package
> > selection is not necessary: the installer will install the
> > workstation product as defined. Tweaks, customizations and software
> > additions should be performed after the installation.
> >
> > One aspect of storage configuration that will be needed is support
> > for dual-boot setups (preserving preexisting Windows or OS X
> > installations), since e.g. students may be required to run
> > software on those platforms for their coursework.
> >
> > gnome-initial-setup already provides support for post-install user
> > creation, language selection, timezone configuration, etc. If
> > necessary, it should be extended to cover all required setup
> > tasks.
>
>
> I'm not even sure where to begin here. The system installer discussion
> probably needs to have its own thread.

+1

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Stephen Gallagher]

Replies inline; I cut out the places where we were in agreement.


On 02/25/2014 04:47 PM, Simo Sorce wrote:
> On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:

>>> === Firewall ===
>>>
>>> A firewall in its default configuration may not interfere with
>>> the normal operation of programs installed by default.
>
> I do not understand what "normal operation" means here. What is
> normal is in part determined by what the user of the system wants
> to accomplish.
>
>> I would extend this statement to include that the deployment of
>> Server Roles should also adjust the firewall operation in a
>> manner consistent with user expectation.
>
> Are we going to use something like firewalld or something else ?
> Should we have the firewall configured by default, or not ?
>


I think that we should have a firewall configured by default, yes.


>>> We should detect when the system is on a public or untrusted
>>> network and prevent the user from unwanted sharing of e.g.
>>> music or other media in this situation. A firewall (and network
>>> zones as currently implemented by firewalld) may or may not be
>>> part of a solution to this.
>>>
>>
>> The concept of network zones should probably be basically ignored
>> for Fedora Server, as we should generally default to closing all
>> ports except for those made available for installed Roles. (Also,
>> the Role configuration should optionally be able to specify on
>> which interfaces it wishes to operate, so we can restrict
>> internal vs. external operation in a multi-homed environment).
>
> What do we gain from a firewall that any application can poke holes
> at ? Can someone state the benefits, or a situation where the
> default configuration would be safer with a firewall ?
>


This is not "any application". This is Server Roles. If a Server Role
can't be seen through the firewall, it's broken. As I noted above, I
do think that part of Role configuration needs to be whether it's
visible on certain interfaces.


>>> === Problem reporting ===
>>>
>>> Problems and error conditions (e.g. kernel oopses, Selinux
>>> AVCs, application crashes, OOM, disk errors) should all be
>>> reported in the systemd journal.
>>
>> Ack
>
> Is there another place they may be reported to ?
>


They each have individual places where they might end up if not drawn
together in the journal. This is basically just formalizing the
current plan of record with journald.


>>> Sending this information to a central place (like abrt does for
>>> crashes today) should be possible, but not mandatory.
>>> Depending on the use case, it may be turned off, enabled
>>> manually on a case-by-case basis, or entirely automatic without
>>> user intervention.
>>>
>>
>>
>> In the case of the Fedora Server, I think that reporting
>> information to a central location must be mandatory. Most servers
>> in real-world deployment are headless in a datacenter somewhere.
>> Administrators will need to be able to see all issues from a
>> standard console.
>
> There is a problem with sending information from things like abrtd
> to a central location by default, in that sensitive information may
> get disclosed unless the log server is reached only through
> authenticated and encrypted connections. Ideally we have a way to
> signal the trustworthiness of the log and change behavior
> accrodingly and automatically. Whether we can do this in the
> short/medium term I do not know.
>
> But technically rsyslog can secure connections and even do mutual
> authentication as it supports both TLS and GSSAPI. I also discussed
> at DevConf.cz with the rsyslog maintainer some secure
> store-and-forward techniques to use with ephemeral encryption keys
> and such so it is an option.
>
>> Also, we need to keep in mind that the majority of servers will
>> *not* have visibility to the internet, so transmitting ABRT
>> results directly to Bugzilla is often impossible. We will need to
>> be able to aggregate the issues on a network-local management
>> server. (Note: IMHO this is not a blocker requirement on F21)
>
> Whether it is "possible" or not automatic transmission is almost
> always inappropriate IMO. Too much potentially sensitive info can
> be transmitted with these kinds of reports, they have to be
> validated and approved for transmission by an admin.
>
> I think this should be an actual requirement for the Server
> platform.
>


You make excellent points. This is a piece we're going to have to
spend some time thinking about. I hope that Miloslav will chime in
here, as he has a lot of first-hand knowledge on this front.

>>
>>> === Account handling ===
>>>
>>> SSSD is providing the backing storage for identity management.
>>> For 'managed' scenarios (e.g. the 'developer in a large
>>> organization' use case of the PRD), it will be possible to
>>> configure it to rely on a directory service for this
>>> information. The accountsservice is providing a D-Bus interface
>>> for user account information; this may be integrated into SSSD
>>> at some point.
>>>
>>> Depending on their needs, application and services can either
>>> use the POSIX APIs (getpwent(), etc) or the accountsservice
>>> D-Bus interface to obtain user information.
>>>
>>
>>
>> As the Fedora Server is more likely than Workstation to require
>> central management, I think we need to adopt this
>> wholeheartedly. Also, realmd should be considered a core piece of
>> our story, as it enables automatic configuration of SSSD with
>> either FreeIPA (our Domain Controller Role) or Active Directory
>> (Microsoft Windows Domain Controller).
>
> +1 (though I have a conflict of interest here :-)
>


I am, of course, equally guilty of this conflict of interest. :)


>>> === Software updates ===
>>>
>>> gnome-software will use PackageKit with the hawkey backend to
>>> obtain and install software updates for packaged applications
>>> and the OS itself. The recommendation for applications is to
>>> use the PackageKit APIs to interact with the underlying
>>> packaging system.
>>>
>>
>>
>> Software updates on a server system should be designed in such a
>> way that they can be enforced centrally. With Fedora Server, this
>> probably means picking one of the common config management
>> systems such as Puppet, Chef, Red Hat Satellite or else relying
>> on OpenLMI for performing central software upgrades.
>
> I think you forgot spacewalk here.
>


It wasn't meant to be an exhaustive list.


>> For single-server manipulation, I think we should focus on
>> supporting yum/dnf.
>
> I think yum/successor CLI tool should be the default here indeed.
>
>>> === Miscellaneous system information ===
>>>
>>> System locale, timezone, hostname, etc. will be managed
>>> through the services provided by systemd for this purpose. See
>>> developer documentation for
>>> [http://www.freedesktop.org/wiki/Software/systemd/localed/
>>> localed],
>>> [http://www.freedesktop.org/wiki/Software/systemd/timedated/
>>> timedated] and
>>> [http://www.freedesktop.org/wiki/Software/systemd/hostnamed/
>>> hostnamed]
>>>
>>
>>
>> I also think we should stick with the systemd-offered mechanisms
>> for this functionality (and I know that Cockpit is already
>> interfacing with much of it).
>
> To be honest I find hostnamed quite inadequate for a server case as
> it introduced confusion in the naming and by default will mangle
> perfectly valid fqdns that the admin want to assign to the
> machine.
>
> I think we should carefully evaluate these mechanisms.
>
> For example, messing up with the hostname often has annoying
> consequences when a server is enrolled into a central identity
> management system.
>


True, we probably want to work with them to disallow hostname changes
while a machine is enrolled in a domain. I think that the interface
here is what we want; we can work on improving the execution.


>
>>> === Virtualization ===
>>>
>>> libvirt-daemon will be used to manage virtualization
>>> capabilities.
>>>
>>
>>
>> We probably want to use libvirt-daemon for virtualization and
>> focus on systemd-nspawn for containerization.
>
> what about libvirt-lxc/docker ?
>

Docker is moving away from libvirt-lxc towards systemd-nspawn (and I
believe the latest releases have experimental support for this
already). I think we probably want to meet them there.


>>> === Display manager ===
>>>
>>> gdm will be used as the display manager. It is responsible for
>>> showing a login screen on each seat. It will be able to
>>> launch both X-based sessions and Wayland sessions.
>>>
>>> Desktop environments are expected to make themselves known as
>>> an available session option on the login screen by dropping a
>>> .desktop file into /usr/share/xsessions (or its wayland
>>> equivalent).
>>>
>>> Other facilities provided by the display manager include screen
>>> unlock authentication and user switching.
>>>
>>
>>
>> Display manager is irrelevant to the Server product.
>
> We already discussed in some cases we will need them as some
> server software unfortunately need a grpahical session for
> installation/configuration purposes.
>
> So we should have at least a recommendation of how to start a
> graphical session if required, even if it is just a manual startx
> or if the recommendation is to use Xvnc and a vnc client or other
> similar options.
>


Valid points. We should start by deciding if we want to bite this off
right now or defer it for a future release, though. Getting this right
might be a challenge.


>>> === Accessibility ===
>>>
>>> The accessibility support in the workstation includes a screen
>>> reader, a high-contrast theme and a zoom capability, amongst
>>> others. The screen reading is provided through orca, which runs
>>> as a session service and requires the at-spi infrastructure.
>>> Applications are expected to provide suitable information to
>>> the screen reader via the toolkit's accessibility support.
>>> Applications are also expected to work acceptably in the
>>> high-contrast theme. The zoom is implemented in the desktop
>>> shell and does not need any application support.
>>>
>>
>>
>> Accessibility on the server is a topic I'm fairly comfortable
>> with deferring to the management tools such as Cockpit and
>> Katello/Foreman. On the pure command-line, I think the most we
>> can do is assert that any interactive operation we enable should
>> have a configurable timeout to deal with potentially slow
>> typists.
>
> We should at least support braille devices out of the box for
> console interaction IMO.
>

I hadn't thought of that. Thanks for bringing it up.


>>> === Graphics ===
>>>
>>> The workstation session will switch to using a Wayland
>>> compositor as soon as feasible. Until then, it will be based on
>>> X11. Even after the switch, an X server will be included, so
>>> applications can either connect to Wayland natively, or run as
>>> an X client.
>>>
>>
>>
>> Not applicable
>
> See above.


Ack


>
>>> === Media support ===
>>>
>>> Sound hardware and audio streams will be managed by pulseaudio.
>>> Applications are recommended to use the
>>> [http://gstreamer.freedesktop.org/documentation/ gstreamer]
>>> framework for media playback.
>>>
>>
>>
>> Not applicable
>
> There are server side media streamers, DLNA, etc.. we can defer
> taking any action but it is incorrect to say that a server os has
> nothing to do with media support.
>


Well, I'm not sure that fits in terms of our Fedora Server platform at
least. We might want to explicitly state it as a non-goal though.


>>> === Appearance ===
>>>
>>> The workstation will ship with a single theme, which will have
>>> support for the included toolkits: gtk3, qt and gtk2.
>>> Applications are expected to work well with this theme, as well
>>> as with the high-contrast theme that is used for accessibility.
>>> The theme will include a dark variant that applications can opt
>>> into using (this is most suitable for certain content-focused
>>> applications). The theme also includes an icon theme that
>>> provides named icons according to the icon-naming spec, plus
>>> symbolic variants.
>>>
>>> We will be using the Adwaita theme, with a yet-to-be-written qt
>>> variant.
>>>
>>
>>
>> As for "appearance", my view is that Cockpit should be the
>> official "face" of the Fedora Server. Opinions welcome :)
>
> Should we say something about how the shell is configured,
> defaults, bash-completion, vim-enhanced/emacs/other plugins ?
>

Perhaps... I'm not sure if we need to go to that particular level of
detail, but if you want to write it up, I'm sure no one will argue :)

[Jonathan Dieter]

On Tue, 2014-02-25 at 16:47 -0500, Simo Sorce wrote:
> On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:
> > I would extend this statement to include that the deployment of Server
> > Roles should also adjust the firewall operation in a manner consistent
> > with user expectation.
>
> Are we going to use something like firewalld or something else ?

Just want to ask this question again, with an additional one. What does
firewalld give us that iptables doesn't in a server environment? Should
we default to iptables instead? Are there other alternatives we should
consider?

Jonathan

[Stephen Gallagher]

On 02/26/2014 03:03 AM, Jonathan Dieter wrote:
> On Tue, 2014-02-25 at 16:47 -0500, Simo Sorce wrote:
>> On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:
>>> I would extend this statement to include that the deployment of
>>> Server Roles should also adjust the firewall operation in a
>>> manner consistent with user expectation.
>>
>> Are we going to use something like firewalld or something else ?
>
> Just want to ask this question again, with an additional one. What
> does firewalld give us that iptables doesn't in a server
> environment? Should we default to iptables instead? Are there
> other alternatives we should consider?
>

About two years ago now, some members of product management did a
customer tour to see how people are actually using RHEL and Fedora in
production environments.

The overwhelming majority of real-world deployments disable the Linux
kernel firewall (iptables) entirely and rely exclusively on perimeter
security. The reason they cited for this was this: iptables is nearly
impossible to manage centrally. This is primarily because the only
interface to manipulating iptables are highly-complex command-line
tools that have to be executed in a shell.

The main advantage that we get from firewalld is that it is providing
a public D-BUS interface that we can use to connect central management
tools (such as puppet) to apply a complete set of rules in one go (as
opposed to the necessarily procedural approach we are currently faced
with, which is reading the current state, parsing it, determining
which changes need to be made and then performing the diff... all
manually and racy)

[Jonathan Dieter]

On Wed, 2014-02-26 at 08:24 -0500, Stephen Gallagher wrote:
> On 02/26/2014 03:03 AM, Jonathan Dieter wrote:
> > On Tue, 2014-02-25 at 16:47 -0500, Simo Sorce wrote:
> >> On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:
> >>> I would extend this statement to include that the deployment of
> >>> Server Roles should also adjust the firewall operation in a
> >>> manner consistent with user expectation.
> >>
> >> Are we going to use something like firewalld or something else ?
> >
> > Just want to ask this question again, with an additional one. What
> > does firewalld give us that iptables doesn't in a server
> > environment? Should we default to iptables instead? Are there
> > other alternatives we should consider?
> >
>
> About two years ago now, some members of product management did a
> customer tour to see how people are actually using RHEL and Fedora in
> production environments.
>
> The overwhelming majority of real-world deployments disable the Linux
> kernel firewall (iptables) entirely and rely exclusively on perimeter
> security. The reason they cited for this was this: iptables is nearly
> impossible to manage centrally. This is primarily because the only
> interface to manipulating iptables are highly-complex command-line
> tools that have to be executed in a shell.
>
> The main advantage that we get from firewalld is that it is providing
> a public D-BUS interface that we can use to connect central management
> tools (such as puppet) to apply a complete set of rules in one go (as
> opposed to the necessarily procedural approach we are currently faced
> with, which is reading the current state, parsing it, determining
> which changes need to be made and then performing the diff... all
> manually and racy)

Ok, that makes sense.

Thanks,
Jonathan

[Michael R. Davis]

On 02/26/2014 03:03 AM, Jonathan Dieter wrote:
> On Tue, 2014-02-25 at 16:47 -0500, Simo Sorce wrote:
>> On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:
>>> I would extend this statement to include that the deployment of
>>> Server Roles should also adjust the firewall operation in a
>>> manner consistent with user expectation.
>>
>> Are we going to use something like firewalld or something else ?
 
The function by which to open a port on the firewall should be a consistent API regardless of the firewall back end.  And should stay consistent for a long period.
   
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/12c546b9/attachment.html>

[Bruno Wolff III]

On Wed, Feb 26, 2014 at 08:24:18 -0500,
Stephen Gallagher <sgallagh at redhat.com> wrote:
>
>The main advantage that we get from firewalld is that it is providing
>a public D-BUS interface that we can use to connect central management
>tools (such as puppet) to apply a complete set of rules in one go (as
>opposed to the necessarily procedural approach we are currently faced
>with, which is reading the current state, parsing it, determining
>which changes need to be made and then performing the diff... all
>manually and racy)

You can also update iptable rules in a non-racy way if you are willing to
drop packects (which can happen in networks anyway, so most things
should be able to cope).

nftables provides atomic updates:
http://wiki.nftables.org/wiki-nftables/index.php/Atomic_rule_replacement
So that might be another option.

[David Timothy Strauss]

On Wed, Feb 26, 2014 at 5:24 AM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> The main advantage that we get from firewalld is that it is providing
> a public D-BUS interface that we can use to connect central management
> tools (such as puppet) to apply a complete set of rules in one go (as
> opposed to the necessarily procedural approach we are currently faced
> with, which is reading the current state, parsing it, determining
> which changes need to be made and then performing the diff... all

We manage iptables by using an iptables.d directory, dropping rules
into it, and then using the summation of those rules on firewall
configuration reloads.

[Simo Sorce]

On Wed, 2014-02-26 at 10:03 +0200, Jonathan Dieter wrote:
> On Tue, 2014-02-25 at 16:47 -0500, Simo Sorce wrote:
> > On Tue, 2014-02-25 at 15:42 -0500, Stephen Gallagher wrote:
> > > I would extend this statement to include that the deployment of Server
> > > Roles should also adjust the firewall operation in a manner consistent
> > > with user expectation.
> >
> > Are we going to use something like firewalld or something else ?
>
> Just want to ask this question again, with an additional one. What does
> firewalld give us that iptables doesn't in a server environment? Should
> we default to iptables instead? Are there other alternatives we should
> consider?

To be honest my question is more about: what is the point of doing
this ?

Do we have applications that we do not trust and open unwanted ports ?
If we do not trust them why do we install them ?
If we trust them why do we firewall them ?

Considering that the default policy on Fedora is not not start daemon
automatically I am trying to understand why having a firewall configured
by default is a good idea.

Note that I am not saying it is not, but it seem one of those Security
Dogma that has gone on w/o much formalizing the actual reasons why it
makes sense to have a local firewall installed.

Keep in mind that I make an absolute distinction between local firewall
and perimeter firewall, the latter is about not trusting all machines in
a network to be configured correctly or according to an organization
policy which is a completely different use case from a local firewall.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Reindl Harald]

Am 26.02.2014 18:39, schrieb Simo Sorce:
> Do we have applications that we do not trust and open unwanted ports?
> If we do not trust them why do we install them?

"we" as Fedora is not in the game to decide what a user
wants to be reachable because you do not know the exact
environment

> If we trust them why do we firewall them ?

because in doubt you *have* open ports and do not know
the network the enduser is connected to

> Considering that the default policy on Fedora is not not start daemon
> automatically I am trying to understand why having a firewall configured
> by default is a good idea.

to prevent what happend in the yum-upgrade to F19

* samba pulls cups-libs -> cups-libs pulls avahi-libs -> avahi-libs pulls avahi daemon
avahi daemon is enabled at install, it was not installed before the upgrade
voila you have a listening service pulled by careless packaging

> Note that I am not saying it is not, but it seem one of those Security
> Dogma that has gone on w/o much formalizing the actual reasons why it
> makes sense to have a local firewall installed.

nothing has gone, in the case above without iptables avahi would
have been accessable from the WAN on 4 machines, frankly you can
have installed samba but not enabled for a lot of reasons and
then you are at exactly the situation above

> Keep in mind that I make an absolute distinction between local firewall
> and perimeter firewall, the latter is about not trusting all machines in
> a network to be configured correctly or according to an organization
> policy which is a completely different use case from a local firewall

* there are also servers with public WAN connections
* security is *always* depth of defense, nothing ever will change that

in case of a sane network you have as much barriers as possible
beause every one of them could fail by mistake - if it was the
only barrier you have a problem, if you have depth of defense
you have a timewindow to realize a mistake on whatever layer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/6c186e48/attachment.sig>

[Matthew Miller]

On Wed, Feb 26, 2014 at 12:39:31PM -0500, Simo Sorce wrote:
> Considering that the default policy on Fedora is not not start daemon
> automatically I am trying to understand why having a firewall configured
> by default is a good idea.

It is required by network policy at at least the two large universities
where I worked. Now, whether it provides defense-in-depth or just a checkbox
item is another issue, but it's nice to have Fedora default to being
compliant with typical requirements.

--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>

[Stephen John Smoogen]

On 26 February 2014 12:31, Matthew Miller <mattdm at fedoraproject.org> wrote:

> On Wed, Feb 26, 2014 at 12:39:31PM -0500, Simo Sorce wrote:
> > Considering that the default policy on Fedora is not not start daemon
> > automatically I am trying to understand why having a firewall configured
> > by default is a good idea.
>
> It is required by network policy at at least the two large universities
> where I worked. Now, whether it provides defense-in-depth or just a
> checkbox
> item is another issue, but it's nice to have Fedora default to being
> compliant with typical requirements.
>
>
And pretty much every .gov and .mil site I know of and quite a few .com
sites. Firewalls by default are so far into various configuration
management requirements that you get to spend years trying to undo it and
will only come out with needing a firewall and antivirus also.

As Reindl pointed out, we can't guarantee we have no services on by
default.. all it takes is the law of unintended consquences before or after
RC1 and you have something no one notices until after a release (or it is
considered by the release group to not be a problem because we have a
firewall already.).


--
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/d9cc1a3e/attachment-0001.html>

[R P Herrold]

On Wed, 26 Feb 2014, Simo Sorce wrote:

> If we trust them why do we firewall them ?

The lure of the Sirens, and parallel construction in language
leads one astray here. A security model may specify running
proxies, or interior trusted toward exterior untrusted network
firewalling, because we do not and cannot know about unknown
vulnerabilities

-- Russ herrold

[Miloslav Trmač]

2014-02-26 18:39 GMT+01:00 Simo Sorce <simo at redhat.com>:

> To be honest my question is more about: what is the point of doing
> this ?
>
> Do we have applications that we do not trust and open unwanted ports ?
> If we do not trust them why do we install them ?
> If we trust them why do we firewall them ?
>
> Considering that the default policy on Fedora is not not start daemon
> automatically I am trying to understand why having a firewall configured
> by default is a good idea.
>

AFAICS there are basically these possible ways to answer the question, each
valid in some situations:

0) The computer is a router, and applying policy on traffic is its specific
job. (This is clearly a special situation that doesn't affect the question
of default setup.)

1) The computer is assumed to be competently administered[1] on a
homogenous network. This implies that any service running with an open
port is intended to run and have that port open, so there is no point with
restricting it with a firewall. There is obviously no point in restricting
closed ports with a firewall. With this assumption, firewall should be
either completely absent or permitting almost all traffic (or perhaps
enforcing some kind of minimal policy, filtering out clearly bogus packets)
by default.

2) The computer is assumed to be administered by people who make mistakes
from time to time; in such a situation having a firewall by default serves
as an extra step that "nudges" the administrators to revisit their
assumptions and intentions: "Now that your httpd/database is running, did
you really want it accessible by the net, or only by localhost?" With this
assumption, a firewall should be present, and blocking incoming connections
by default; it makes sense to make it fairly easy to enable access to a
service after setting it up.

3) The computer is assumed to be running on a non-homogenous network, e.g.
providing some services to an internal network and fewer services to a
public-facing network. It is unsafe, or at least risky, to expose
internal-only services on the public network. With this assumption, a
firewall should be present, and blocking incoming connections by default;
the system shouldn't be enabling access to a service after setting it up,
and leave this to manual administrators' action (unless the system
understands how precisely is the network non-homogenous).

4) The computer is assumed to be already compromised, or highly likely to
be compromised. In that case, a firewall blocking incoming connections by
default would stop *some* communication, but it makes *almost no difference*:
Instead of opening a port and waiting for an incoming connection, the
attacker can make an outgoing connection, which is not restricted by the
usual firewall setup. Because most home routers doing NAT implicitly act
as firewalls that block incoming connections, it would be almost
*unexpected* if the attacker tried to open a listening port nowadays.
Overall, I don't think the firewall is effective in this scenario in most
cases, so this scenario doesn't matter in the discussion.[2]

Note that apart from 4), the assumptions are about the *computer*, not th*e
individual services*, and are mutually exclusive; it doesn't make sense to
treat one set of ports differently from another. This is the reason for my
objections to the suggestion that the default setup of the firewall should
differ between roles.
Mirek


[1] ... and competently designed; let's assume that's true for Fedora
Server :)

[2] One thing to consider, and other OSes have been moving in that
direction, is to have a firewall that doesn't block *ports* but blocks
*executables*. This makes the attacker's work somewhat harder, in that
they couldn't just use a standardized shell code to download a new binary
and execute it, but they would have to continue manipulating an existing
process to make the connections on their behalf. In a sense, we already
have this capability with SELinux; and It's unclear how much difference
does it make - would this only cause the attacker to add a socket() call to
the shell code, and leave the rest of the activity to a subprocess, for
example?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140303/2c7fa85a/attachment-0001.html>

[Simo Sorce]

On Mon, 2014-03-03 at 19:08 +0100, Miloslav Trmač wrote:
> 1) The computer is assumed to be competently administered[1] on a
> homogenous network. This implies that any service running with an
> open port is intended to run and have that port open, so there is no
> point with restricting it with a firewall. There is obviously no
> point in restricting closed ports with a firewall. With this
> assumption, firewall should be either completely absent or permitting
> almost all traffic (or perhaps enforcing some kind of minimal policy,
> filtering out clearly bogus packets) by default.
>
I think that you badly characterize this case (and perhaps 2 too).

What I think you fail to address is the case where the administrator is
competent but the *users* of the system may not be.

In this case services configured and run by the administrator should
poke holes, but in general other ports should be firewalled because
users may inadvertently run services that open ports w/o realizing it.

This is the case where a firewall make sense as a default installation
even though roles are allowed to automatically poke holes at
configuration time.

Simo.
>
--
Simo Sorce * Red Hat, Inc * New York

[Miloslav Trmač]

2014-03-03 23:13 GMT+01:00 Simo Sorce <simo at redhat.com>:

> On Mon, 2014-03-03 at 19:08 +0100, Miloslav Trmač wrote:
> > 1) The computer is assumed to be competently administered[1] on a
> > homogenous network. This implies that any service running with an
> > open port is intended to run and have that port open, so there is no
> > point with restricting it with a firewall. There is obviously no
> > point in restricting closed ports with a firewall. With this
> > assumption, firewall should be either completely absent or permitting
> > almost all traffic (or perhaps enforcing some kind of minimal policy,
> > filtering out clearly bogus packets) by default.
> >
> I think that you badly characterize this case (and perhaps 2 too).
>
> What I think you fail to address is the case where the administrator is
> competent but the *users* of the system may not be.
>
> In this case services configured and run by the administrator should
> poke holes, but in general other ports should be firewalled because
> users may inadvertently run services that open ports w/o realizing it.
>
> This is the case where a firewall make sense as a default installation
> even though roles are allowed to automatically poke holes at
> configuration time.
>

Even in such a case it would not make sense for the *role* to decide
whether to poke holes for itself: either the system roles are assumed to be
competently administered or not, and in both cases all roles on the system
should be treated the same.

And I don't think the case you describe is frequent in the firsts place.
It requires:

- A multi-user UNIX system (in itself becoming rare, everyone has a
powerful personal computer, and remoting the GUI loses features; you would
have a git server or a file server or a VPN server, but not so much a
general shell server)
- A multi-user UNIX system that *also* provides other roles at the same
time (tightly coupling things that probably shouldn't be coupled, using
separate VMs would result in more flexibility)
- A system that is reachable from an environment that is more hostile
than the users (e.g. with a public IP address); again note that the
firewall setups we are talking about don't affect outgoing connections,
only incoming connections matter.

So, a multi-user server with a public IP address: Yes, there is a specific
and frequent kind of them - web hosting servers; but those are also not
something that we really can support as a default setup, and longer-term
I'd expect them to go the OpenShift way, giving each user a separate
container with a separate network namespace. Other than web hosting, are
public multi-user servers with ability of users to run arbitrary code
really that frequent?
Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140304/3ee96621/attachment.html>

[Reindl Harald]

Am 04.03.2014 13:40, schrieb Miloslav Trmač:
> Even in such a case it would not make sense for the /role/ to decide whether to poke holes for itself: either the
> system roles are assumed to be competently administered or not, and in both cases all roles on the system should be
> treated the same.
>
> And I don't think the case you describe is frequent in the firsts place. It requires:
>
> * A multi-user UNIX system (in itself becoming rare, everyone has a powerful personal computer, and remoting the
> GUI loses features; you would have a git server or a file server or a VPN server, but not so much a general
> shell server)
> * A multi-user UNIX system that /also/ provides other roles at the same time (tightly coupling things that
> probably shouldn't be coupled, using separate VMs would result in more flexibility)
> * A system that is reachable from an environment that is more hostile than the users (e.g. with a public IP
> address); again note that the firewall setups we are talking about don't affect outgoing connections, only
> incoming connections matter.
>
> So, a multi-user server with a public IP address: Yes, there is a specific and frequent kind of them - web hosting
> servers; but those are also not something that we really can support as a default setup, and longer-term I'd expect
> them to go the OpenShift way, giving each user a separate container with a separate network namespace. Other than
> web hosting, are public multi-user servers with ability of users to run arbitrary code really that frequent?
> Mirek

first:
ship whatever OS with shields down and no packet filter blocking anything incoming
is a flawed design and unacceptable (no matter if it is a server or a workstation)

second:
you never know in which way a port get opened and if it is because packaging
bugs as i showed whith avahi pulled for no reason - nonody can gurantee that
similar things are not happening in a future point of time

third:
even if you install a service or webapplication and enable it that does not mean
at the same time it should be reachable from the web - in most cases the
opposite is true because after the first start you typically configure and
test whatever you have installed on localhost, otherwise the admin should
not do an IT job

fourth:
"to run arbitrary code really that frequent" define that - any scripting language
with commands like exec(), system() and so on is in danger to run code if it is
not perfectly secured what a default installation is unable to do

so there is still a difference if any badly written script executes code and is
able to open a unprivileged port and having that one immediately reachable from
the WAN or blocked by a packet filter giving the admin a timewindow to realize
something is going wrong before more damage happens

and so finally: now, in the past and in any future you have to block any incoming
connection in whatever operating system by default or nobody with security knowledge
will install that "product" because he is aware about the wrong security attitude
of it's creators and that it is not worth the time for a second look

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140304/877f3f38/attachment.sig>

[Miloslav Trmač]

2014-03-04 13:51 GMT+01:00 Reindl Harald <h.reindl at thelounge.net>:

> second:
>
third:
>
(lots snipped).

Those are cases I have also numbered 2) and 3) earlier in the thread :) I
agree that a firewall by default, for all services, makes sense in these
situations.

The email you are quoting is my objections to having the default *differ
between roles*. I think that our cases 2) and 3) either apply across the
whole computer, or not at all; so having the firewall allow access to some
roles by default and not to others doesn't make sense.

fourth:
> "to run arbitrary code really that frequent" define that - any scripting
> language
> with commands like exec(), system() and so on is in danger to run code if
> it is
> not perfectly secured what a default installation is unable to do
>

I think that's addressed by my case 4): a firewall that only blocks
incoming connections is not all that useful in this situation.

and so finally: now, in the past and in any future you have to block any
> incoming
> connection in whatever operating system by default or nobody with security
> knowledge
> will install that "product" because he is aware about the wrong security
> attitude
> of it's creators and that it is not worth the time for a second look
>

I'm not at all insisting on having no firewall by default, but my interest
in appeasing cargo-culting requests like "you must run a firewall and
antivirus and antispyware" is really limited. Not exactly zero, but fairly
close to zero. *Why* do we need to block incoming connections? If we have
a reason, are we actually deploying the firewall in a way that does handle
that reason?

I see having a firewall running by default, but punching holes in it by
default, without explicit user involvement, as such a case: the underlying
reason to have a firewall seems to be defeated by the way the firewall is
being used.
Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140304/bdf99827/attachment.html>

[Simo Sorce]

On Tue, 2014-03-04 at 14:07 +0100, Miloslav Trmač wrote:
> I see having a firewall running by default, but punching holes in it
> by default, without explicit user involvement, as such a case: the
> underlying reason to have a firewall seems to be defeated by the way
> the firewall is being used.

Here lies the error of your reasoning.

Roles do not do anything without *explicit user involvement*.
You actually have to install *and* setup a role on your system to poke
any hole.
And not poking holes for some roles makes no sense, because the role can
only be used (in the common case) if it is reachable from the network,
and if it is unreachable it does not work.

One of the assumptions for roles is that we want to have them working as
intended once the setup is complete.

Roles that are not clear cases, as said in the last meeting, will offer
a way for the admin to tell what to do, however their default will
depend on what we think is the best default.

For example I think the best default for the domain controller role will
be to open the firewall, while the best default for the database role
will be to keep it closed.

The point is: roles should provide firewall rules and apply the
appropriate default, however admins should be able to override the
default at setup time.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Miloslav Trmač]

2014-03-04 21:31 GMT+01:00 Simo Sorce <simo at redhat.com>:

> On Tue, 2014-03-04 at 14:07 +0100, Miloslav Trmač wrote:
> > I see having a firewall running by default, but punching holes in it
> > by default, without explicit user involvement, as such a case: the
> > underlying reason to have a firewall seems to be defeated by the way
> > the firewall is being used.
>
> Here lies the error of your reasoning.
>
> Roles do not do anything without *explicit user involvement*.
> You actually have to install *and* setup a role on your system to poke
> any hole.
>

OK, so let's clarify how explicit the involvement is. When the user runs
(fedora-role-deploy $rolename), will this

- Always punch a hole in the firewall, because the "fedora-role-deploy"
was an explicit action?
- Ask the user, and acting on the answer, which was an explicit action?
- Not ask the user, but do what the role thinks is appropriate, because
deploying a role was an explicit action?

My primary objection is to the latest option: If the user can't predict the
effect of their command, I don't think the command was an "explicit" user
action. It's just unpredictable unless you read all documentation, which
many people don't.

And not poking holes for some roles makes no sense, because the role can
> only be used (in the common case) if it is reachable from the network,
> and if it is unreachable it does not work.
>
Yes.

One of the assumptions for roles is that we want to have them working as
> intended once the setup is complete.
>
Yes.

For example I think the best default for the domain controller role will
> be to open the firewall, while the best default for the database role
> will be to keep it closed.
>
That may be *individually* true, but the user gets differing behavior
without having clearly acknowledged or caused such a difference, put
together into a single product doesn't give the user sufficient visibility.
Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140305/5b22c522/attachment.html>

[Simo Sorce]

On Wed, 2014-03-05 at 15:35 +0100, Miloslav Trmač wrote:
> 2014-03-04 21:31 GMT+01:00 Simo Sorce <simo at redhat.com>:
>
> > On Tue, 2014-03-04 at 14:07 +0100, Miloslav Trmač wrote:
> > > I see having a firewall running by default, but punching holes in it
> > > by default, without explicit user involvement, as such a case: the
> > > underlying reason to have a firewall seems to be defeated by the way
> > > the firewall is being used.
> >
> > Here lies the error of your reasoning.
> >
> > Roles do not do anything without *explicit user involvement*.
> > You actually have to install *and* setup a role on your system to poke
> > any hole.
> >
>
> OK, so let's clarify how explicit the involvement is. When the user runs
> (fedora-role-deploy $rolename), will this
>
> - Always punch a hole in the firewall, because the "fedora-role-deploy"
> was an explicit action?
> - Ask the user, and acting on the answer, which was an explicit action?
> - Not ask the user, but do what the role thinks is appropriate, because
> deploying a role was an explicit action?

One of the three depending on the Role, they are all on the table,
because different roles have different properties and defaults.

> My primary objection is to the latest option: If the user can't predict the
> effect of their command, I don't think the command was an "explicit" user
> action. It's just unpredictable unless you read all documentation, which
> many people don't.

I do not understand what you mean. If you deploy a domain controller do
you expect it to be in full working condition when you are done
configuring it through the role deploy command ?
I do very much expect so, and to fullfill that expectation the role
deployment script needs to open the appropriate KRB/LDAP/etc.. ports or
the role is simply non-functional.

Why wouldn't the admin expect that ?

Note that we currently do not do that in the ipa-server-install script
because we didn't have a simple API to call in the past and it is one of
the rough edges, so much so that when the script ends we have to print a
long blurb to tell the admin he has to open all these ports. That sucks,
and very often it happens admins simply turn off the firewall instead of
poking only the necessary holes as result.

> And not poking holes for some roles makes no sense, because the role can
> > only be used (in the common case) if it is reachable from the network,
> > and if it is unreachable it does not work.
> >
> Yes.
>
> One of the assumptions for roles is that we want to have them working as
> > intended once the setup is complete.
> >
> Yes.
>
> For example I think the best default for the domain controller role will
> > be to open the firewall, while the best default for the database role
> > will be to keep it closed.
> >
> That may be *individually* true, but the user gets differing behavior
> without having clearly acknowledged or caused such a difference, put
> together into a single product doesn't give the user sufficient visibility.

I do not understand your point here. Different roles have different
characteristics. Roles that do not open ports by default can warn the
user that they did not do so and tell them what is the role-command to
use to open the default ports for the role.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Miloslav Trmač]

2014-03-05 20:09 GMT+01:00 Simo Sorce <simo at redhat.com>:

> On Wed, 2014-03-05 at 15:35 +0100, Miloslav Trmač wrote:
>
> I do not understand what you mean. If you deploy a domain controller do
> you expect it to be in full working condition when you are done
> configuring it through the role deploy command ?
>

If, say, one week ago I have used exactly the same command to deploy a
database, and I still remember that I had to manually modify the firewall,
why wouldn't I expect the same command to do the same thing about the
domain controller? I'd like the OS commands to behave consistently so that
I don't have to remember too much.

> > For example I think the best default for the domain controller role will
> > > be to open the firewall, while the best default for the database role
> > > will be to keep it closed.
> >
> > That may be *individually* true, but the user gets differing behavior
> > without having clearly acknowledged or caused such a difference, put
> > together into a single product doesn't give the user sufficient
> visibility.
>
> I do not understand your point here. Different roles have different
> characteristics. Roles that do not open ports by default can warn the
> user that they did not do so and tell them what is the role-command to
> use to open the default ports for the role.
>

OK, informing the user[1] would resolve my concern. I'd still prefer the
behavior to be consistent, but this would work.
Mirek

[1] It seems to me that the user needs to be informed *both* when the
service needs the user to modify the firewall, and when it has modified the
firewall without asking, but that's really an UI design question that I
shouldn't be bikeshedding I suppose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/e5bea61a/attachment.html>

[Simo Sorce]

On Thu, 2014-03-06 at 21:39 +0100, Miloslav Trmač wrote:
> 2014-03-05 20:09 GMT+01:00 Simo Sorce <simo at redhat.com>:
>
> > On Wed, 2014-03-05 at 15:35 +0100, Miloslav Trmač wrote:
> >
> > I do not understand what you mean. If you deploy a domain controller do
> > you expect it to be in full working condition when you are done
> > configuring it through the role deploy command ?
> >
>
> If, say, one week ago I have used exactly the same command to deploy a
> database, and I still remember that I had to manually modify the firewall,
> why wouldn't I expect the same command to do the same thing about the
> domain controller? I'd like the OS commands to behave consistently so that
> I don't have to remember too much.

Sorry I do not understand what you are saying here.

What the role tells you is what are the ports it cares about, the
command I suspect will always be the same.
Something like: role <rolename> open-firewall-ports

> > > For example I think the best default for the domain controller role will
> > > > be to open the firewall, while the best default for the database role
> > > > will be to keep it closed.
> > >
> > > That may be *individually* true, but the user gets differing behavior
> > > without having clearly acknowledged or caused such a difference, put
> > > together into a single product doesn't give the user sufficient
> > visibility.
> >
> > I do not understand your point here. Different roles have different
> > characteristics. Roles that do not open ports by default can warn the
> > user that they did not do so and tell them what is the role-command to
> > use to open the default ports for the role.
> >
>
> OK, informing the user[1] would resolve my concern. I'd still prefer the
> behavior to be consistent, but this would work.
> Mirek
>
> [1] It seems to me that the user needs to be informed *both* when the
> service needs the user to modify the firewall, and when it has modified the
> firewall without asking, but that's really an UI design question that I
> shouldn't be bikeshedding I suppose.

Let's not bikeshed then, can we assume that you agree that it is ok for
roles to have different defaults (your caveats applied) ?

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Miloslav Trmač]

2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com>:

> On Thu, 2014-03-06 at 21:39 +0100, Miloslav Trmač wrote:
> > 2014-03-05 20:09 GMT+01:00 Simo Sorce <simo at redhat.com>:
> >
> > > On Wed, 2014-03-05 at 15:35 +0100, Miloslav Trmač wrote:
> > >
> > > I do not understand what you mean. If you deploy a domain controller do
> > > you expect it to be in full working condition when you are done
> > > configuring it through the role deploy command ?
> > >
> >
> > If, say, one week ago I have used exactly the same command to deploy a
> > database, and I still remember that I had to manually modify the
> firewall,
> > why wouldn't I expect the same command to do the same thing about the
> > domain controller? I'd like the OS commands to behave consistently so
> that
> > I don't have to remember too much.
>
> Sorry I do not understand what you are saying here.
>
$ fedora-role-deploy postgresql
# Huh, it is refusing connections?
# Ah, firewall...
$ fedora-role-deploy --open-firewall-ports potgresql
# That's how it is done in Fedora, then. Good to know.

# Time passes...

$ fedora-role-deploy freeipa
# Huh, this is already accessible?


> > OK, informing the user[1] would resolve my concern. I'd still prefer the
> > behavior to be consistent, but this would work.
>
<snip>

> Let's not bikeshed then, can we assume that you agree that it is ok for
> roles to have different defaults (your caveats applied) ?
>
Yes.
Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/6f7e00f6/attachment.html>

[Reindl Harald]

Am 06.03.2014 22:13, schrieb Miloslav Trmač:
> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com <mailto:simo at redhat.com>>:
> Sorry I do not understand what you are saying here.
>
> $ fedora-role-deploy postgresql
> # Huh, it is refusing connections?
> # Ah, firewall...
> $ fedora-role-deploy --open-firewall-ports potgresql
> # That's how it is done in Fedora, then. Good to know.

right direction

> # Time passes...
>
> $ fedora-role-deploy freeipa
> # Huh, this is already accessible?

that must not happen

* not from usability point of view
* not from security point of view - *no* open ports *never ever* as default

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/00205696/attachment.sig>

[Stephen Gallagher]

On 03/06/2014 04:28 PM, Reindl Harald wrote:
>
>
> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
>> <mailto:simo at redhat.com>>: Sorry I do not understand what you are
>> saying here.
>>
>> $ fedora-role-deploy postgresql # Huh, it is refusing
>> connections? # Ah, firewall... $ fedora-role-deploy
>> --open-firewall-ports potgresql # That's how it is done in
>> Fedora, then. Good to know.
>
> right direction
>
>> # Time passes...
>>
>> $ fedora-role-deploy freeipa # Huh, this is already accessible?
>
> that must not happen
>
> * not from usability point of view * not from security point of
> view - *no* open ports *never ever* as default
>

The debate here is where you draw the line as to "what is default".
Deploying a role is *NOT* the same as just installing a package. For
package installs, I absolutely agree that we should never be poking
holes in the firewall.

I can see Simo's point about the expectation that when you tell a
machine "You're a domain controller now!" that it's awkward for it not
to immediately be available, while the same is not necessarily true of
a database (which might only want local access).

So I have no problems at all with Miloslav's suggestion that we just
require an additional argument (which will have to be translated to
the API layer in a sensible way) as part of the configuration.

It probably does hit that fine line between usable and secure
reasonably well.

Of course, the question becomes one of granularity: I doubt that
- --open-firewall-ports is necessarily sufficient. In the case of
multi-homed servers, you still may want to have the service visible
only on a subset of interfaces. I'd suggest
- --open-firewall-ports[=iface1,...] as a reasonable compromise (and
again translated acceptably into the Role config API).

And finally, the config API must also be capable of changing the set
of open interfaces (such as when local testing has passed and the
admin now wants to expose the services publicly).

[Reindl Harald]

Am 06.03.2014 22:43, schrieb Stephen Gallagher:
> On 03/06/2014 04:28 PM, Reindl Harald wrote:
>
>> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
>>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
>>> <mailto:simo at redhat.com>>: Sorry I do not understand what you are
>>> saying here.
>>>
>>> $ fedora-role-deploy postgresql # Huh, it is refusing
>>> connections? # Ah, firewall... $ fedora-role-deploy
>>> --open-firewall-ports potgresql # That's how it is done in
>>> Fedora, then. Good to know.
>
>> right direction
>
>>> # Time passes...
>>>
>>> $ fedora-role-deploy freeipa # Huh, this is already accessible?
>
>> that must not happen
>
>> * not from usability point of view * not from security point of
>> view - *no* open ports *never ever* as default
>
> The debate here is where you draw the line as to "what is default".
> Deploying a role is *NOT* the same as just installing a package. For
> package installs, I absolutely agree that we should never be poking
> holes in the firewall.

i draw the line *strict*

if i deploy whatever role nobody than me is responsible to open
firewall ports because nobody than me can know if it is sane
to do so or what i have planned after the depolyment before
go in production

frankly nobody than me knows for what usage the role is intended
inside the LAN, specific IP's in the LAN or even the whole world
and while nobody than me can now that nobody but me has to open ports

open firewall ports is always the last setp due going in production

there should be no but and if because that is what windows does
and that's why i am using Linux
________________________

recently faced on a Win2008R2 acting as vCenter server

* install VMware packages -> ports in the firewall are opened
* well, iclosed them *all* exept two single LAN IP's
* months later -> update of whatever package
* followed by the monthly security scan inside the LAN
* one check is if the complete vCenter server is *unreachable*
* voila, a few ports opened again

no, i do not want such mis.behavior on any system i would call sane

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/3a51fa14/attachment.sig>

[Stephen John Smoogen]

On 6 March 2014 14:54, Reindl Harald <h.reindl at thelounge.net> wrote:

>
>
> Am 06.03.2014 22:43, schrieb Stephen Gallagher:
> > On 03/06/2014 04:28 PM, Reindl Harald wrote:
> >
> >> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
> >>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
> >>> <mailto:simo at redhat.com>>: Sorry I do not understand what you are
> >>> saying here.
> >>>
> >>> $ fedora-role-deploy postgresql # Huh, it is refusing
> >>> connections? # Ah, firewall... $ fedora-role-deploy
> >>> --open-firewall-ports potgresql # That's how it is done in
> >>> Fedora, then. Good to know.
> >
> >> right direction
> >
> >>> # Time passes...
> >>>
> >>> $ fedora-role-deploy freeipa # Huh, this is already accessible?
> >
> >> that must not happen
> >
> >> * not from usability point of view * not from security point of
> >> view - *no* open ports *never ever* as default
> >
> > The debate here is where you draw the line as to "what is default".
> > Deploying a role is *NOT* the same as just installing a package. For
> > package installs, I absolutely agree that we should never be poking
> > holes in the firewall.
>
> i draw the line *strict*
>
> if i deploy whatever role nobody than me is responsible to open
> firewall ports because nobody than me can know if it is sane
> to do so or what i have planned after the depolyment before
> go in production
>
>
Then in this case, you wouldn't want to use Roles in any form as they
aren't going to help you any. You aren't the target audience for them..
trying to make you the target audience would only work in your environment
and no one elses.


--
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/24d2adc1/attachment.html>

[Stephen Gallagher]

On 03/06/2014 05:06 PM, Stephen John Smoogen wrote:
>
>
>
> On 6 March 2014 14:54, Reindl Harald <h.reindl at thelounge.net
> <mailto:h.reindl at thelounge.net>> wrote:
>
>
>
> Am 06.03.2014 22:43, schrieb Stephen Gallagher:
>> On 03/06/2014 04:28 PM, Reindl Harald wrote:
>>
>>> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
>>>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
> <mailto:simo at redhat.com>
>>>> <mailto:simo at redhat.com <mailto:simo at redhat.com>>>: Sorry I
>>>> do
> not understand what you are
>>>> saying here.
>>>>
>>>> $ fedora-role-deploy postgresql # Huh, it is refusing
>>>> connections? # Ah, firewall... $ fedora-role-deploy
>>>> --open-firewall-ports potgresql # That's how it is done in
>>>> Fedora, then. Good to know.
>>
>>> right direction
>>
>>>> # Time passes...
>>>>
>>>> $ fedora-role-deploy freeipa # Huh, this is already
>>>> accessible?
>>
>>> that must not happen
>>
>>> * not from usability point of view * not from security point
>>> of view - *no* open ports *never ever* as default
>>
>> The debate here is where you draw the line as to "what is
>> default". Deploying a role is *NOT* the same as just installing a
>> package. For package installs, I absolutely agree that we should
>> never be poking holes in the firewall.
>
> i draw the line *strict*
>
> if i deploy whatever role nobody than me is responsible to open
> firewall ports because nobody than me can know if it is sane to do
> so or what i have planned after the depolyment before go in
> production
>
>
> Then in this case, you wouldn't want to use Roles in any form as
> they aren't going to help you any. You aren't the target audience
> for them.. trying to make you the target audience would only work
> in your environment and no one elses.
>

I don't think that's necessarily a fair statement. We fully intend for
the firewall control on these Roles to be easy to turn off and on at
will. Upgrades should never change that state[1]. I don't see any
reason why, under those conditions, Roles couldn't work for Mr. Reindl.


[1] I think I can reasonably assert this without controversy.

[Stephen John Smoogen]

On 6 March 2014 15:12, Stephen Gallagher <sgallagh at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/06/2014 05:06 PM, Stephen John Smoogen wrote:
> >
> >
> >
> > On 6 March 2014 14:54, Reindl Harald <h.reindl at thelounge.net
> > <mailto:h.reindl at thelounge.net>> wrote:
> >
> >
> >
> > Am 06.03.2014 22:43, schrieb Stephen Gallagher:
> >> On 03/06/2014 04:28 PM, Reindl Harald wrote:
> >>
> >>> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
> >>>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
> > <mailto:simo at redhat.com>
> >>>> <mailto:simo at redhat.com <mailto:simo at redhat.com>>>: Sorry I
> >>>> do
> > not understand what you are
> >>>> saying here.
> >>>>
> >>>> $ fedora-role-deploy postgresql # Huh, it is refusing
> >>>> connections? # Ah, firewall... $ fedora-role-deploy
> >>>> --open-firewall-ports potgresql # That's how it is done in
> >>>> Fedora, then. Good to know.
> >>
> >>> right direction
> >>
> >>>> # Time passes...
> >>>>
> >>>> $ fedora-role-deploy freeipa # Huh, this is already
> >>>> accessible?
> >>
> >>> that must not happen
> >>
> >>> * not from usability point of view * not from security point
> >>> of view - *no* open ports *never ever* as default
> >>
> >> The debate here is where you draw the line as to "what is
> >> default". Deploying a role is *NOT* the same as just installing a
> >> package. For package installs, I absolutely agree that we should
> >> never be poking holes in the firewall.
> >
> > i draw the line *strict*
> >
> > if i deploy whatever role nobody than me is responsible to open
> > firewall ports because nobody than me can know if it is sane to do
> > so or what i have planned after the depolyment before go in
> > production
> >
> >
> > Then in this case, you wouldn't want to use Roles in any form as
> > they aren't going to help you any. You aren't the target audience
> > for them.. trying to make you the target audience would only work
> > in your environment and no one elses.
> >
>
> I don't think that's necessarily a fair statement. We fully intend for
> the firewall control on these Roles to be easy to turn off and on at
> will. Upgrades should never change that state[1]. I don't see any
> reason why, under those conditions, Roles couldn't work for Mr. Reindl.
>
>
I didn't say that roles couldn't work, just that he isn't the target
audience. From what I have read through the years, Harald has a very strict
setup which he knows very well and works well for what he needs done.
However doing any sort of configuration management outside of what he has
in place is going to cause problems. They are ones that can be worked
around but you would need to make sure that the default of every role
command is noop. Only after he had configured, edited and audited the tasks
would he want them to be anything else.

Note this isn't meant to be derogatory to H. Reindl and if it comes across
I am sorry.. I have a lot of respect for people who work in such
environments and realize that there is a LOT of need for it. I also know
that if you are designing a product to meet those types of environments you
need to know from the start that 1) nothing happens without express
commands and 2) nothing is to be hard coded but configurable before a role
is deployed. It usually means where you could come up with a 'generic' 60%
solution in 20 lines of code, you now need a 4000 line of code to deal with
all the alternatives and options that will come up.



--
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/bd2f4ca1/attachment-0001.html>

[Reindl Harald]

Am 06.03.2014 23:30, schrieb Stephen John Smoogen:
> I didn't say that roles couldn't work, just that he isn't the target audience.
> From what I have read through the years, Harald has a very strict setup which
> he knows very well and works well for what he needs done

but you do not realize the intention why i care at all!

others not having that strict setup and are at learning
how to deal with their os without dangerous defaults they
may not realize soon enough is the intention

what i consider is "how should a linux system work for
me after the first setup with my knowledge 15 years
ago"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/9b0d5c6b/attachment.sig>

[Stephen John Smoogen]

On 6 March 2014 15:36, Reindl Harald <h.reindl at thelounge.net> wrote:

>
>
> Am 06.03.2014 23:30, schrieb Stephen John Smoogen:
> > I didn't say that roles couldn't work, just that he isn't the target
> audience.
> > From what I have read through the years, Harald has a very strict setup
> which
> > he knows very well and works well for what he needs done
>
> but you do not realize the intention why i care at all!
>
> others not having that strict setup and are at learning
> how to deal with their os without dangerous defaults they
> may not realize soon enough is the intention
>
> what i consider is "how should a linux system work for
> me after the first setup with my knowledge 15 years
> ago"
>

My understanding was that the roles commands were items that the system
administrator ran to set up a system to do a certain task and was set up to
be done for the 60% of the environments which aren't going to play with
defaults in any case. So these were my assumptions:

1) The systems administrator is running these commands.
2) The system administrator level being aimed for is more where they have a
task to do and just want it to work without knowing all these things. (EG
the people who will install cpanel, webadmin, etc without a thought.) We
are just wanting that when they set up those commands they get a working
secure default.
3) The goal is to get these systems up without the admin following the
usual howto of

disable iptables
disable selinux
install package x
install tar-ball from http://reallygoodsite.com/
run cpanel

because they aren't reading anything deeper than that because the problem
they want to solve has nothing to do with the all the packages they are
currently installing. All they want is a web calender and it needs all this
other stuff before they can get it running.

Since these assumptions seem to be wrong, I will bow out of this
conversation.



--
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/8656d4ee/attachment.html>

[Simo Sorce]

On Thu, 2014-03-06 at 15:49 -0700, Stephen John Smoogen wrote:
> My understanding was that the roles commands were items that the
> system administrator ran to set up a system to do a certain task and
> was set up to be done for the 60% of the environments which aren't
> going to play with defaults in any case.

Exactly, the idea of a role is to have a standard way to deploy some
well defined services we classify as 'roles'. The aim is to have the
roles fully functional once configured. The definition of 'fully
functional' is role-specific of course.

> So these were my assumptions:
> 1) The systems administrator is running these commands.
> 2) The system administrator level being aimed for is more where they
> have a task to do and just want it to work without knowing all these
> things. (EG the people who will install cpanel, webadmin, etc without
> a thought.) We are just wanting that when they set up those commands
> they get a working secure default.
> 3) The goal is to get these systems up without the admin following the
> usual howto of

[snip]

Yes, this is correct, moreover if the admin is expert and has taken the
time to read the role documentation (or has experimented previously) I
expect he will be able to find the additional command line switches of
the 'configure-role' command to change defaults for specific high level
configuration items if he needs/wants to.

So in the firewall case I see a more expert admin passing in at
invocation time the policy he wants to enforce when it comes to opening
firewall ports. If he doesn't, the role-default will be used instead.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Russell Doty]

On Fri, 2014-03-07 at 10:52 -0500, Simo Sorce wrote:
> On Thu, 2014-03-06 at 15:49 -0700, Stephen John Smoogen wrote:
> > My understanding was that the roles commands were items that the
> > system administrator ran to set up a system to do a certain task and
> > was set up to be done for the 60% of the environments which aren't
> > going to play with defaults in any case.
>
> Exactly, the idea of a role is to have a standard way to deploy some
> well defined services we classify as 'roles'. The aim is to have the
> roles fully functional once configured. The definition of 'fully
> functional' is role-specific of course.
>
> > So these were my assumptions:
> > 1) The systems administrator is running these commands.
> > 2) The system administrator level being aimed for is more where they
> > have a task to do and just want it to work without knowing all these
> > things. (EG the people who will install cpanel, webadmin, etc without
> > a thought.) We are just wanting that when they set up those commands
> > they get a working secure default.
> > 3) The goal is to get these systems up without the admin following the
> > usual howto of
>
> [snip]
>
> Yes, this is correct, moreover if the admin is expert and has taken the
> time to read the role documentation (or has experimented previously) I
> expect he will be able to find the additional command line switches of
> the 'configure-role' command to change defaults for specific high level
> configuration items if he needs/wants to.
>
> So in the firewall case I see a more expert admin passing in at
> invocation time the policy he wants to enforce when it comes to opening
> firewall ports. If he doesn't, the role-default will be used instead.
>
> Simo.
>
To jump in here, the majority of customers (based on primary and
secondary research) turn off the Linux firewall.

They do this for two reasons:

* The Linux firewall interferes with applications.

* The Linux firewall can't be centrally managed.

Firewalld is a starting point for enabling centralized management of
Linux firewalls. Server Roles are a step toward having the firewall not
interfere with the application, by configuring the firewall as part of
the application installation.

Server Roles should improve security by encouraging more people to leave
the Linux Firewall turned on.

Russ

[Simo Sorce]

On Thu, 2014-03-06 at 17:12 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/06/2014 05:06 PM, Stephen John Smoogen wrote:
> >
> >
> >
> > On 6 March 2014 14:54, Reindl Harald <h.reindl at thelounge.net
> > <mailto:h.reindl at thelounge.net>> wrote:
> >
> >
> >
> > Am 06.03.2014 22:43, schrieb Stephen Gallagher:
> >> On 03/06/2014 04:28 PM, Reindl Harald wrote:
> >>
> >>> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
> >>>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
> > <mailto:simo at redhat.com>
> >>>> <mailto:simo at redhat.com <mailto:simo at redhat.com>>>: Sorry I
> >>>> do
> > not understand what you are
> >>>> saying here.
> >>>>
> >>>> $ fedora-role-deploy postgresql # Huh, it is refusing
> >>>> connections? # Ah, firewall... $ fedora-role-deploy
> >>>> --open-firewall-ports potgresql # That's how it is done in
> >>>> Fedora, then. Good to know.
> >>
> >>> right direction
> >>
> >>>> # Time passes...
> >>>>
> >>>> $ fedora-role-deploy freeipa # Huh, this is already
> >>>> accessible?
> >>
> >>> that must not happen
> >>
> >>> * not from usability point of view * not from security point
> >>> of view - *no* open ports *never ever* as default
> >>
> >> The debate here is where you draw the line as to "what is
> >> default". Deploying a role is *NOT* the same as just installing a
> >> package. For package installs, I absolutely agree that we should
> >> never be poking holes in the firewall.
> >
> > i draw the line *strict*
> >
> > if i deploy whatever role nobody than me is responsible to open
> > firewall ports because nobody than me can know if it is sane to do
> > so or what i have planned after the depolyment before go in
> > production
> >
> >
> > Then in this case, you wouldn't want to use Roles in any form as
> > they aren't going to help you any. You aren't the target audience
> > for them.. trying to make you the target audience would only work
> > in your environment and no one elses.
> >
>
> I don't think that's necessarily a fair statement. We fully intend for
> the firewall control on these Roles to be easy to turn off and on at
> will. Upgrades should never change that state[1]. I don't see any
> reason why, under those conditions, Roles couldn't work for Mr. Reindl.
>
>
> [1] I think I can reasonably assert this without controversy.

weeeelll, we had some ports change in freeipa, we used to open 8443 and
then we changed to proxy everything via 443, so technically we would
like to 'close' a port on update if we were back then :-)

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Reindl Harald]

Am 06.03.2014 23:06, schrieb Stephen John Smoogen:
>
>
>
> On 6 March 2014 14:54, Reindl Harald <h.reindl at thelounge.net <mailto:h.reindl at thelounge.net>> wrote:
>
>
>
> Am 06.03.2014 22:43, schrieb Stephen Gallagher:
> > On 03/06/2014 04:28 PM, Reindl Harald wrote:
> >
> >> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
> >>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com <mailto:simo at redhat.com>
> >>> <mailto:simo at redhat.com <mailto:simo at redhat.com>>>: Sorry I do not understand what you are
> >>> saying here.
> >>>
> >>> $ fedora-role-deploy postgresql # Huh, it is refusing
> >>> connections? # Ah, firewall... $ fedora-role-deploy
> >>> --open-firewall-ports potgresql # That's how it is done in
> >>> Fedora, then. Good to know.
> >
> >> right direction
> >
> >>> # Time passes...
> >>>
> >>> $ fedora-role-deploy freeipa # Huh, this is already accessible?
> >
> >> that must not happen
> >
> >> * not from usability point of view * not from security point of
> >> view - *no* open ports *never ever* as default
> >
> > The debate here is where you draw the line as to "what is default".
> > Deploying a role is *NOT* the same as just installing a package. For
> > package installs, I absolutely agree that we should never be poking
> > holes in the firewall.
>
> i draw the line *strict*
>
> if i deploy whatever role nobody than me is responsible to open
> firewall ports because nobody than me can know if it is sane
> to do so or what i have planned after the depolyment before
> go in production
>

> Then in this case, you wouldn't want to use Roles in any form as they
> aren't going to help you any

even if - i would be the target as 3rd party by machines of people
using roles and not aware that they need to plug the network cable
before the first boot and secure the setup before connect it to
the network

anybody now saying "that is not windows you can connect a linux
to the internet without get infected" is lofty and may regret
that attitude sonner or later

> You aren't the target audience for them.. trying to make you the target audience
> would only work in your environment and no one elses.

what are you talking about?

honestly i find it only bizarre that in the year 2014 *anybody* considers
to open any port without *explicit confirmation* of the sysadmin installing
the system or even install a OS without a packetfilter



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/2aaa4bbd/attachment.sig>

[Reindl Harald]

Am 06.03.2014 23:36, schrieb Simo Sorce:
> On Thu, 2014-03-06 at 17:12 -0500, Stephen Gallagher wrote:
>> I don't think that's necessarily a fair statement. We fully intend for
>> the firewall control on these Roles to be easy to turn off and on at
>> will. Upgrades should never change that state[1]. I don't see any
>> reason why, under those conditions, Roles couldn't work for Mr. Reindl.
>>
>>
>> [1] I think I can reasonably assert this without controversy.
>
> weeeelll, we had some ports change in freeipa, we used to open 8443 and
> then we changed to proxy everything via 443, so technically we would
> like to 'close' a port on update if we were back then :-)

no - you would that only if you are changing my servers configuration
to listen on a different port which would be a no-go - and if you
are now find a argument why doing so it's the best against defaults
someone later may regret after it is too late

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140306/0c949ab5/attachment.sig>

[Miloslav Trmač]

2014-03-06 22:43 GMT+01:00 Stephen Gallagher <sgallagh at redhat.com>:

> On 03/06/2014 04:28 PM, Reindl Harald wrote:
> > Am 06.03.2014 22:13, schrieb Miloslav Trmač:
> >> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
> >> <mailto:simo at redhat.com>>: Sorry I do not understand what you are
> >> saying here.
> >>
> >> $ fedora-role-deploy postgresql # Huh, it is refusing
> >> connections?
>
>> # Ah, firewall...
>
>> $ fedora-role-deploy --open-firewall-ports potgresql
>
>> # That's how it is done in Fedora, then. Good to know.
>
<snip>

> So I have no problems at all with Miloslav's suggestion that we just
> require an additional argument (which will have to be translated to
> the API layer in a sensible way) as part of the configuration.
>

So the above was confusing, that's not what I wanted to suggest. The
--open-firewall-ports was to be basically "firewall-cmd --permanent
--add-service=postgresql", i.e. change the firewall, not a re-deploy of the
role. (Though it could have actually been a re-deploy, given our earlier
conversation about cattle-like deployment.)


> Of course, the question becomes one of granularity: I doubt that
> - --open-firewall-ports is necessarily sufficient. In the case of
> multi-homed servers, you still may want to have the service visible
> only on a subset of interfaces. I'd suggest
> - --open-firewall-ports[=iface1,...] as a reasonable compromise (and
> again translated acceptably into the Role config API).
>

Wouldn't it be simplest to just use (firewall-cmd --permanent
--zone=$my_zone ...) directly? We could of course build a
"fedora-role-firewall" facade over it if necessary, but firewalld already
has all the necessary functionality AFAICS.

And finally, the config API must also be capable of changing the set
> of open interfaces (such as when local testing has passed and the
> admin now wants to expose the services publicly).
>
That's a firewalld command away, as well.
Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140307/6efd84d9/attachment-0001.html>

[Stephen Gallagher]

On 03/07/2014 09:56 AM, Miloslav Trmač wrote:
> 2014-03-06 22:43 GMT+01:00 Stephen Gallagher <sgallagh at redhat.com
> <mailto:sgallagh at redhat.com>>:
>
> On 03/06/2014 04:28 PM, Reindl Harald wrote:
>> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
>>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
> <mailto:simo at redhat.com>
>>> <mailto:simo at redhat.com <mailto:simo at redhat.com>>>: Sorry I do
> not understand what you are
>>> saying here.
>>>
>>> $ fedora-role-deploy postgresql # Huh, it is refusing
>>> connections?
>
>>> # Ah, firewall...
>
>>> $ fedora-role-deploy --open-firewall-ports potgresql
>
>>> # That's how it is done in Fedora, then. Good to know.
>
> <snip>
>
> So I have no problems at all with Miloslav's suggestion that we
> just require an additional argument (which will have to be
> translated to the API layer in a sensible way) as part of the
> configuration.
>
>
> So the above was confusing, that's not what I wanted to suggest.
> The --open-firewall-ports was to be basically "firewall-cmd
> --permanent --add-service=postgresql", i.e. change the firewall,
> not a re-deploy of the role. (Though it could have actually been a
> re-deploy, given our earlier conversation about cattle-like
> deployment.)
>
>
> Of course, the question becomes one of granularity: I doubt that -
> --open-firewall-ports is necessarily sufficient. In the case of
> multi-homed servers, you still may want to have the service
> visible only on a subset of interfaces. I'd suggest -
> --open-firewall-ports[=iface1,...] as a reasonable compromise (and
> again translated acceptably into the Role config API).
>
>
> Wouldn't it be simplest to just use (firewall-cmd --permanent
> --zone=$my_zone ...) directly? We could of course build a
> "fedora-role-firewall" facade over it if necessary, but firewalld
> already has all the necessary functionality AFAICS.
>
> And finally, the config API must also be capable of changing the
> set of open interfaces (such as when local testing has passed and
> the admin now wants to expose the services publicly).
>
> That's a firewalld command away, as well.


I think we're agreeing completely here. That's how I would expect we'd
do it "under the hood" too. I was just talking about things from
another layer of abstraction. --open-firewall-ports would be a wrapper
around "ask the role what ports it wants to use, then tell firewalld
to open them on the appropriate interfaces".

[Chris Murphy]

adding desktop@ since they are also looking at file system options

On Feb 25, 2014, at 1:42 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:

>> === File system ===
>>
>> The default file system type for workstation installs should be
>> btrfs.
>
> The default file system is definitely up for some debate, but I'd make
> an argument for using XFS atop LVM[1] for the default filesystem in
> the Fedora Server, at least in part because Red Hat's storage experts
> have done the research for us already and determined that XFS is the
> recommended fit for Red Hat Enterprise Linux 7.

XFS is a really good idea for Server.

Follow-up questions:

- Can Server and Workstation WG's choose different defaults for their product's installers?

- Other than lack of shrink support in XFS, I'd say XFS is suitable for Workstation as well. Would the Workstation WG have concerns about the lack of fs shrink support in the default file system? [1]

>
> Btrfs still makes me somewhat nervous, given that its upstream doesn't
> consider it stable[3].

That wiki entry appears old. The stable aspect was about disk format, which is now stable. And also the experimental description was removed in kernel 3.13. [2]

My main two concerns with Btrfs:
1. With even minor problems users sometimes go straight to the big hammer approach with "btrfsck/btrfs check --repair" rather than the recommended approaches. Remounting with -o recovery, and even using a newer kernel are recommended on linux-btrfs@ significantly more often than btrfs check --repair.

It's a fair question how fail safe the offline repair utility currently is, and should be. In my monitoring of linux-btrfs@, even if btrfs check --repair made things worse, the offline btrfs restore utility enabled files to be extracted.

2. Supporting multiple device volumes in Anaconda. Although multiple device Btrfs volumes work very well when devices are working, there's no device failure notification yet. When a device fails, the volume becomes read-only; and the volume isn't mountable (or bootable) without the use of "degraded" mount option. While this can be done as a boot parameter, it's sort of a non-obvious thing for the typical user. I think it's valid for either WG to consider reducing exposure by dropping Anaconda support for it, or placarding the feature somehow.


[1] LVM Thin Provisioning, if ready for production prime time as a default, is a work around. It's actually better than fs resize anyway.

[2] http://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg29945.html



Chris Murphy

[Adam Williamson]

On Tue, 2014-02-25 at 15:53 -0700, Chris Murphy wrote:
> adding desktop@ since they are also looking at file system options
>
> On Feb 25, 2014, at 1:42 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
>
> >> === File system ===
> >>
> >> The default file system type for workstation installs should be
> >> btrfs.
> >
> > The default file system is definitely up for some debate, but I'd make
> > an argument for using XFS atop LVM[1] for the default filesystem in
> > the Fedora Server, at least in part because Red Hat's storage experts
> > have done the research for us already and determined that XFS is the
> > recommended fit for Red Hat Enterprise Linux 7.
>
> XFS is a really good idea for Server.
>
> Follow-up questions:
>
> - Can Server and Workstation WG's choose different defaults for their
> product's installers?

Given my understanding of anaconda's architecture I don't believe this
would *technically* present a significant problem. anaconda already has
the concept of being used to install different products, and using
different defaults for various things depending on what product it's
being used to install: this is how RHEL can have different defaults from
Fedora.

It would be best to ask the anaconda devs, though. Maybe they think it's
a horrible hack and don't want to extend it any further than their
paychecks require. CCing bcl and dcantrell.

In terms of *policy*, it'd be up to FESCo, I guess. It seems like a
perfectly reasonable point of variance between products to me.

> - Other than lack of shrink support in XFS, I'd say XFS is suitable
> for Workstation as well. Would the Workstation WG have concerns about
> the lack of fs shrink support in the default file system? [1]
>
> >
> > Btrfs still makes me somewhat nervous, given that its upstream doesn't
> > consider it stable[3].
>
> That wiki entry appears old. The stable aspect was about disk format,
> which is now stable. And also the experimental description was removed
> in kernel 3.13. [2]

<snip>

In addition to Chris' points, we discussed btrfs at this week's QA
meeting, and agreed that even though it's really not QA's 'job', it
seems sensible to just check if Desktop WG has talked to the devs who
have, up until now, been taking the job of deciding when btrfs is 'ready
for primetime' and developed a plan. Is the btrfs-by-default part of the
current tech spec more of a long term aspiration, or is it on the table
for F21? Have the concerns about its readiness been evaluated and
checked with the domain experts?

Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[David Cantrell]

On Tue, Feb 25, 2014 at 03:04:30PM -0800, Adam Williamson wrote:
> On Tue, 2014-02-25 at 15:53 -0700, Chris Murphy wrote:
> > adding desktop@ since they are also looking at file system options
> >
> > On Feb 25, 2014, at 1:42 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> >
> > >> === File system ===
> > >>
> > >> The default file system type for workstation installs should be
> > >> btrfs.
> > >
> > > The default file system is definitely up for some debate, but I'd make
> > > an argument for using XFS atop LVM[1] for the default filesystem in
> > > the Fedora Server, at least in part because Red Hat's storage experts
> > > have done the research for us already and determined that XFS is the
> > > recommended fit for Red Hat Enterprise Linux 7.
> >
> > XFS is a really good idea for Server.
> >
> > Follow-up questions:
> >
> > - Can Server and Workstation WG's choose different defaults for their
> > product's installers?
>
> Given my understanding of anaconda's architecture I don't believe this
> would *technically* present a significant problem. anaconda already has
> the concept of being used to install different products, and using
> different defaults for various things depending on what product it's
> being used to install: this is how RHEL can have different defaults from
> Fedora.a

If the Server and Workstation trees are separate composes, you can have a
different default filesystem.

> It would be best to ask the anaconda devs, though. Maybe they think it's
> a horrible hack and don't want to extend it any further than their
> paychecks require. CCing bcl and dcantrell.

It's not as horrible of a hack as it was in the past.

> In terms of *policy*, it'd be up to FESCo, I guess. It seems like a
> perfectly reasonable point of variance between products to me.

I say the default Fedora filesystem should be up for vote, much like FESCo
members or the code name for a release.

Thanks,

--
David Cantrell <dcantrell at redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT

[Bruno Wolff III]

On Tue, Feb 25, 2014 at 18:11:35 -0500,
David Cantrell <dcantrell at redhat.com> wrote:
>
>I say the default Fedora filesystem should be up for vote, much like FESCo
>members or the code name for a release.

I don't think that is a good idea. I'd rather see a small group of subject
experts make the decision for the default, than have a large group of
Fedora contributors vote, who may not be in a good position to judge the
relative merits of file systems.

[Stephen Gallagher]

On 02/26/2014 08:58 AM, Bruno Wolff III wrote:
> On Tue, Feb 25, 2014 at 18:11:35 -0500, David Cantrell
> <dcantrell at redhat.com> wrote:
>>
>> I say the default Fedora filesystem should be up for vote, much
>> like FESCo members or the code name for a release.
>
> I don't think that is a good idea. I'd rather see a small group of
> subject experts make the decision for the default, than have a
> large group of Fedora contributors vote, who may not be in a good
> position to judge the relative merits of file systems.


Yeah, for the Products, I think this is well within the purview of the
Working Group to decide (hopefully by seeking expert opinion first).

[Josh Boyer]

On Wed, Feb 26, 2014 at 8:58 AM, Bruno Wolff III <bruno at wolff.to> wrote:
> On Tue, Feb 25, 2014 at 18:11:35 -0500,
> David Cantrell <dcantrell at redhat.com> wrote:
>>
>>
>> I say the default Fedora filesystem should be up for vote, much like FESCo
>> members or the code name for a release.
>
>
> I don't think that is a good idea. I'd rather see a small group of subject
> experts make the decision for the default, than have a large group of Fedora
> contributors vote, who may not be in a good position to judge the relative
> merits of file systems.

Yeah, agreed here. Everyone wants the latest shiniest thing, even if
that thing isn't ready. I really don't want to wade through tons of
bug reports for btrfs just because it has a lot of hype.

josh

[Colin Walters]

On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer <jwboyer at fedoraproject.org>
wrote:
>
> Yeah, agreed here. Everyone wants the latest shiniest thing, even if
> that thing isn't ready. I really don't want to wade through tons of
> bug reports for btrfs just because it has a lot of hype.
>
Also, right now cloud is plain old ext4. Let's see if we can ship
*all* of the filesystems! It'll be fun!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/22d1bb13/attachment.html>

[Jaroslav Reznik]

----- Original Message -----
> On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer <jwboyer at fedoraproject.org>
> wrote:
>
>
>
> Yeah, agreed here. Everyone wants the latest shiniest thing, even if that
> thing isn't ready. I really don't want to wade through tons of bug reports
> for btrfs just because it has a lot of hype.
>
> Also, right now cloud is plain old ext4. Let's see if we can ship *all* of
> the filesystems! It'll be fun!

Yep, a lot of fun - three different file systems for free different products.
And we are back to the question how much these products could differ - with
limited resources we have right now - at least short term. Who can answer it
- filesystem/kernel guys, if they are able and willing to support all
potential filesystem, as David stated, it's possible in Anaconda but again
the same question if the team would be able to maintain more filesystems
support with high bar in terms of quality (even for example brtfs limited
to bare minimum), QA... And it could be pretty confusing for users but that's
up to us/marketing to explain that products aim specific goal and it's for
good (if we would be able to support it - then it's for good, if not...).

Adding devel list to CC - I expect another topic Base should be involved
too.

And no, no elections for file system. It's really up to WGs and coordination
with the rest teams.

Jaroslav

> _______________________________________________
> server mailing list
> server at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/server

[Josh Boyer]

On Wed, Feb 26, 2014 at 10:18 AM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> ----- Original Message -----
>> On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer <jwboyer at fedoraproject.org>
>> wrote:
>>
>>
>>
>> Yeah, agreed here. Everyone wants the latest shiniest thing, even if that
>> thing isn't ready. I really don't want to wade through tons of bug reports
>> for btrfs just because it has a lot of hype.
>>
>> Also, right now cloud is plain old ext4. Let's see if we can ship *all* of
>> the filesystems! It'll be fun!
>
> Yep, a lot of fun - three different file systems for free different products.
> And we are back to the question how much these products could differ - with
> limited resources we have right now - at least short term. Who can answer it
> - filesystem/kernel guys, if they are able and willing to support all

I'm a kernel guy. We already ship all of these filesystems. People
already do installs with all of them. Really, it's more about what we
consider _sane_ as the default for most users that don't know the
difference, and not about shipping them in general.

> potential filesystem, as David stated, it's possible in Anaconda but again
> the same question if the team would be able to maintain more filesystems
> support with high bar in terms of quality (even for example brtfs limited
> to bare minimum), QA... And it could be pretty confusing for users but that's

I don't think the support aspect is going to change much either way.
The only thing I see possibly happening is more focus on btrfs, but I
know my team isn't in a position to spend any significant amount of
time on that right now.

josh

[David Cantrell]

On Wed, Feb 26, 2014 at 10:18:12AM -0500, Jaroslav Reznik wrote:
> ----- Original Message -----
> > On Wed, Feb 26, 2014 at 9:25 AM, Josh Boyer <jwboyer at fedoraproject.org>
> > wrote:
> >
> >
> >
> > Yeah, agreed here. Everyone wants the latest shiniest thing, even if that
> > thing isn't ready. I really don't want to wade through tons of bug reports
> > for btrfs just because it has a lot of hype.
> >
> > Also, right now cloud is plain old ext4. Let's see if we can ship *all* of
> > the filesystems! It'll be fun!
>
> Yep, a lot of fun - three different file systems for free different products.
> And we are back to the question how much these products could differ - with
> limited resources we have right now - at least short term. Who can answer it
> - filesystem/kernel guys, if they are able and willing to support all
> potential filesystem, as David stated, it's possible in Anaconda but again
> the same question if the team would be able to maintain more filesystems
> support with high bar in terms of quality (even for example brtfs limited
> to bare minimum), QA... And it could be pretty confusing for users but that's
> up to us/marketing to explain that products aim specific goal and it's for
> good (if we would be able to support it - then it's for good, if not...).

I think filesystem variance across different Fedoras really impacts QA more
than us. We already support a lot of filesystems, but the real hit is the
QA test matrix.

> Adding devel list to CC - I expect another topic Base should be involved
> too.
>
> And no, no elections for file system. It's really up to WGs and coordination
> with the rest teams.

--
David Cantrell <dcantrell at redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT

[Adam Williamson]

On Wed, 2014-02-26 at 10:24 -0500, David Cantrell wrote:

> > Yep, a lot of fun - three different file systems for free different products.
> > And we are back to the question how much these products could differ - with
> > limited resources we have right now - at least short term. Who can answer it
> > - filesystem/kernel guys, if they are able and willing to support all
> > potential filesystem, as David stated, it's possible in Anaconda but again
> > the same question if the team would be able to maintain more filesystems
> > support with high bar in terms of quality (even for example brtfs limited
> > to bare minimum), QA... And it could be pretty confusing for users but that's
> > up to us/marketing to explain that products aim specific goal and it's for
> > good (if we would be able to support it - then it's for good, if not...).
>
> I think filesystem variance across different Fedoras really impacts QA more
> than us. We already support a lot of filesystems, but the real hit is the
> QA test matrix.

Well, there is an indirect impact on devel.

As I said, it's about what we decide is 'release blocking'. The historic
approach there, and the one that's really simplest and makes most sense,
is 'guided path is release blocking, custom is not'. The more choice
there is on the guided path, the more release blocking codepaths we
have, and the more release blocker bugs you folks get to treadmill.

If, for instance, we ditched LVM thinp and btrfs from the guided path
dropdown, we cut the number of potentially release blocking paths by 50%
immediately. It won't necessarily cut the number of release blocking
bugs by precisely 50%, but it's pretty hard to believe it wouldn't cut
the number at *all*. And I know you folks get tired of the release
blocker treadmill.

Remember, what QA release validation testing ultimately *results in* is
blocker bugs :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Feb 26, 2014, at 5:33 PM, Josef Bacik <josef at toxicpanda.com> wrote:
>
> Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default.
>
>
OK good, that's definitive. Thanks Josef.

So my thought is Workstation WG choices: parity with Server WG, whatever they choose; or plain ext4; or keep things the same with LVM + ext4.

And on the question of an alternate choice (what currently appears in the Automatic/Guided path's Partition Scheme pop-up menu) the WG's might consider this too, even whether an alternate is desired. Because from a my personal QA perspective, I'd like to see the two products agree on either the default or an alternate so we don't have four total possible paths combined, which today means 100 testable outcomes. One or two paths is ideal; three might be OK. Four is like
 chickens with no heads, running.


Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/b03f2f53/attachment.html>

[Stephen Gallagher]

On 02/27/2014 12:18 AM, Chris Murphy wrote:
>
> On Feb 26, 2014, at 5:33 PM, Josef Bacik <josef at toxicpanda.com
> <mailto:josef at toxicpanda.com>> wrote:
>>
>> Just popping in here to say that btrfs is not ready to be default
>> in Fedora yet. Optional is fine but not default.
>>
>>
> OK good, that's definitive. Thanks Josef.
>
> So my thought is Workstation WG choices: parity with Server WG,
> whatever they choose; or plain ext4; or keep things the same with
> LVM + ext4.
>
> And on the question of an alternate choice (what currently appears
> in the Automatic/Guided path's Partition Scheme pop-up menu) the
> WG's might consider this too, even whether an alternate is desired.
> Because from a my personal QA perspective, I'd like to see the two
> products agree on either the default or an alternate so we don't
> have four total possible paths combined, which today means 100
> testable outcomes. One or two paths is ideal; three might be OK.
> Four is like
 chickens with no heads, running.
>

Speaking for myself, I have a slight preference on using XFS-on-LVM
for the default filesystem in the Fedora Server, but if both of the
other Products would prefer ext4-on-LVM, I suppose we could negotiate.

If we can arrange things so we only have a single installer with
different install targets (at least for the net install), I'd consider
the reduction in testing effort at least worthy of argument at being
more valuable than the filesystem choice.

Question for the cloud folks:

I realize that XFS is a difficult pill to swallow for /boot, due to
your use of syslinux instead of GRUB2. If the Server and Workstation
groups decide to settle on both using XFS-on-LVM for the main
partitions, we could *probably* also compromise on using ext4 for just
/boot.


Directed more broadly at all three products:

Formal proposal (for discussion): All three products agree to use ext4
for /boot and XFS-on-LVM for all other partitions in the "guided"
mode. All is fair game in the "custom" mode.

Also, for the sake of everyone's sanity, as we discuss this specific
proposal, let's hold the conversation to devel at lists.fedoraproject.org
(making this the last cross-posted message in the thread).

[Rui Tiago Cação Matos]

On 27 February 2014 13:43, Stephen Gallagher <sgallagh at redhat.com> wrote:
> Formal proposal (for discussion): All three products agree to use ext4
> for /boot and XFS-on-LVM for all other partitions in the "guided"
> mode. All is fair game in the "custom" mode.

What's the point of using LVM for the root filesystem?

Rui

[Matthew Miller]

On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
> I realize that XFS is a difficult pill to swallow for /boot, due to
> your use of syslinux instead of GRUB2. If the Server and Workstation
> groups decide to settle on both using XFS-on-LVM for the main
> partitions, we could *probably* also compromise on using ext4 for just
> /boot.

Right now, the cloud images are unpartitioned. In some cloud providers
(e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that
assumes the image is just one partition, not a disk image. We could change
that (and I kind of want to anyway, for consistency), but it would be...
change. Having a separate /boot is also problematic (read: wasteful) for
ultra-small images, and adds complexity a lot of users are going to frown
at. So..... if by "/boot" you mean "the partition that /boot happens to be
on, even if it is /", then I think we're good. Otherwise we will have to
figure something else out.


--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>

[Dennis Gilmore]

On Thu, 27 Feb 2014 15:01:47 -0500
Matthew Miller <mattdm at fedoraproject.org> wrote:

> On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
> > I realize that XFS is a difficult pill to swallow for /boot, due to
> > your use of syslinux instead of GRUB2. If the Server and Workstation
> > groups decide to settle on both using XFS-on-LVM for the main
> > partitions, we could *probably* also compromise on using ext4 for
> > just /boot.
>
> Right now, the cloud images are unpartitioned. In some cloud providers
> (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that
> assumes the image is just one partition, not a disk image. We could
> change that (and I kind of want to anyway, for consistency), but it
> would be... change. Having a separate /boot is also problematic
> (read: wasteful) for ultra-small images, and adds complexity a lot of
> users are going to frown at. So..... if by "/boot" you mean "the
> partition that /boot happens to be on, even if it is /", then I think
> we're good. Otherwise we will have to figure something else out.

u-boot has zero support for xfs so arm systems will have to use ext4
for /boot at least as well. which would mean / if users chose to not
use a separate /boot partition

Dennis

[Josh Boyer]

On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 27 Feb 2014 15:01:47 -0500
> Matthew Miller <mattdm at fedoraproject.org> wrote:
>
>> On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
>> > I realize that XFS is a difficult pill to swallow for /boot, due to
>> > your use of syslinux instead of GRUB2. If the Server and Workstation
>> > groups decide to settle on both using XFS-on-LVM for the main
>> > partitions, we could *probably* also compromise on using ext4 for
>> > just /boot.
>>
>> Right now, the cloud images are unpartitioned. In some cloud providers
>> (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that
>> assumes the image is just one partition, not a disk image. We could
>> change that (and I kind of want to anyway, for consistency), but it
>> would be... change. Having a separate /boot is also problematic
>> (read: wasteful) for ultra-small images, and adds complexity a lot of
>> users are going to frown at. So..... if by "/boot" you mean "the
>> partition that /boot happens to be on, even if it is /", then I think
>> we're good. Otherwise we will have to figure something else out.
>
> u-boot has zero support for xfs so arm systems will have to use ext4
> for /boot at least as well. which would mean / if users chose to not
> use a separate /boot partition

Or, as an alternative, XFS support could be added to u-boot and/or
syslinux. Never eliminate the possibility of actually writing code to
fix problems. All it takes is someone willing to do work ;).

josh

[Matthew Miller]

On Thu, Feb 27, 2014 at 04:03:06PM -0500, Josh Boyer wrote:
> Or, as an alternative, XFS support could be added to u-boot and/or
> syslinux. Never eliminate the possibility of actually writing code to
> fix problems. All it takes is someone willing to do work ;).

Right, and as I understand it, there actually _is_ some level of support,
and there was a GSoC project related to it a couple of years ago.



--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>

[Dennis Gilmore]

On Thu, 27 Feb 2014 16:03:06 -0500
Josh Boyer <jwboyer at fedoraproject.org> wrote:

> On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore <dennis at ausil.us>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Thu, 27 Feb 2014 15:01:47 -0500
> > Matthew Miller <mattdm at fedoraproject.org> wrote:
> >
> >> On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote:
> >> > I realize that XFS is a difficult pill to swallow for /boot, due
> >> > to your use of syslinux instead of GRUB2. If the Server and
> >> > Workstation groups decide to settle on both using XFS-on-LVM for
> >> > the main partitions, we could *probably* also compromise on
> >> > using ext4 for just /boot.
> >>
> >> Right now, the cloud images are unpartitioned. In some cloud
> >> providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use
> >> the kernel that assumes the image is just one partition, not a
> >> disk image. We could change that (and I kind of want to anyway,
> >> for consistency), but it would be... change. Having a
> >> separate /boot is also problematic (read: wasteful) for
> >> ultra-small images, and adds complexity a lot of users are going
> >> to frown at. So..... if by "/boot" you mean "the partition
> >> that /boot happens to be on, even if it is /", then I think we're
> >> good. Otherwise we will have to figure something else out.
> >
> > u-boot has zero support for xfs so arm systems will have to use ext4
> > for /boot at least as well. which would mean / if users chose to not
> > use a separate /boot partition
>
> Or, as an alternative, XFS support could be added to u-boot and/or
> syslinux. Never eliminate the possibility of actually writing code to
> fix problems. All it takes is someone willing to do work ;).
>
> josh

the issue we have with u-boot is that we may have to change how we do
some things. Some hardware we have relied on vendor provided u-boots.
likely we would need to ship and update the u-boot the vendor provides
to add functionality. the trimslice for instance has a u-boot that only
boots from ext2 or ext3 and lacks ext4 support. the vendor has said
that they will not be shipping any more u-boot updates, so in the case
there we are going to have to ship our own update to support the work
that has been going on upstream to unify features and boot support. I
have been working upstream to get things moved over to using the
available pxe/extlinux linux support.

longer term /boot on xfs may be possible, but it will take work

Dennis

[Matthew Miller]

On Wed, Feb 26, 2014 at 02:59:00PM +0000, Colin Walters wrote:
> >Yeah, agreed here. Everyone wants the latest shiniest thing, even if
> >that thing isn't ready. I really don't want to wade through tons of
> >bug reports for btrfs just because it has a lot of hype.
> Also, right now cloud is plain old ext4. Let's see if we can ship
> *all* of the filesystems! It'll be fun!

Cloud could switch to XFS along with server. The main problem is that it'd
make us revisit booting -- either 1) some work into lightening up grub2, 2)
testing and possibly enhancing syslinux's xfs support, or 3) a separate
/boot with a different filesystem. I don't really love any of those options.

--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>

[Stephen Gallagher]

On 02/26/2014 11:14 AM, Matthew Miller wrote:
> On Wed, Feb 26, 2014 at 02:59:00PM +0000, Colin Walters wrote:
>>> Yeah, agreed here. Everyone wants the latest shiniest thing,
>>> even if that thing isn't ready. I really don't want to wade
>>> through tons of bug reports for btrfs just because it has a lot
>>> of hype.
>> Also, right now cloud is plain old ext4. Let's see if we can
>> ship *all* of the filesystems! It'll be fun!
>
> Cloud could switch to XFS along with server. The main problem is
> that it'd make us revisit booting -- either 1) some work into
> lightening up grub2, 2) testing and possibly enhancing syslinux's
> xfs support, or 3) a separate /boot with a different filesystem. I
> don't really love any of those options.
>

Could you go into more detail about those various issues?

My off-the-cuff guess is that you don't currently plan to use GRUB2
because it's heavyweight for your use-case? So you'd either need to
shrink it down or else find a way to allow syslinux to work (either by
supporting XFS in it or using a /boot with ext4)?

I'm trying to deconstruct that from the proposed solutions, so please
correct me if I'm way off base.

[Matthew Miller]

On Wed, Feb 26, 2014 at 11:30:47AM -0500, Stephen Gallagher wrote:
> > Cloud could switch to XFS along with server. The main problem is
> > that it'd make us revisit booting -- either 1) some work into
> > lightening up grub2, 2) testing and possibly enhancing syslinux's
> > xfs support, or 3) a separate /boot with a different filesystem. I
> > don't really love any of those options.
> Could you go into more detail about those various issues?
>
> My off-the-cuff guess is that you don't currently plan to use GRUB2
> because it's heavyweight for your use-case? So you'd either need to
> shrink it down or else find a way to allow syslinux to work (either by
> supporting XFS in it or using a /boot with ext4)?

That's pretty much it. :)



--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>

[Matthias Clasen]

On Wed, 2014-02-26 at 11:14 -0500, Matthew Miller wrote:
> On Wed, Feb 26, 2014 at 02:59:00PM +0000, Colin Walters wrote:
> > >Yeah, agreed here. Everyone wants the latest shiniest thing, even if
> > >that thing isn't ready. I really don't want to wade through tons of
> > >bug reports for btrfs just because it has a lot of hype.
> > Also, right now cloud is plain old ext4. Let's see if we can ship
> > *all* of the filesystems! It'll be fun!
>
> Cloud could switch to XFS along with server. The main problem is that it'd
> make us revisit booting -- either 1) some work into lightening up grub2, 2)
> testing and possibly enhancing syslinux's xfs support, or 3) a separate
> /boot with a different filesystem. I don't really love any of those options.

I'm always dubious of 'there shall be only one' decrees - be it
installers or desktop environments or file systems.

Also, as has already been pointed out: there are Fedora systems out
there using ext4, xfs, btrfs and probably a few other file systems
today. If we now suddenly change track and consider btrfs not 'safe
enough', wasn't it pretty irresponsible of us to let people use it for
their installations ?

For the workstation, I think the options are

- switch to btrfs soon to give it the exposure it needs to get ready
(while being careful to limit the supported features, as suse does)

- stick with ext4 until we have some user-visible features (time
slider...) that make a switch to btrfs very attractive

[Stephen Gallagher]

On 02/26/2014 11:42 AM, Matthias Clasen wrote:
>
> On Wed, 2014-02-26 at 11:14 -0500, Matthew Miller wrote:
>> On Wed, Feb 26, 2014 at 02:59:00PM +0000, Colin Walters wrote:
>>>> Yeah, agreed here. Everyone wants the latest shiniest thing,
>>>> even if that thing isn't ready. I really don't want to wade
>>>> through tons of bug reports for btrfs just because it has a
>>>> lot of hype.
>>> Also, right now cloud is plain old ext4. Let's see if we can
>>> ship *all* of the filesystems! It'll be fun!
>>
>> Cloud could switch to XFS along with server. The main problem is
>> that it'd make us revisit booting -- either 1) some work into
>> lightening up grub2, 2) testing and possibly enhancing syslinux's
>> xfs support, or 3) a separate /boot with a different filesystem.
>> I don't really love any of those options.
>
> I'm always dubious of 'there shall be only one' decrees - be it
> installers or desktop environments or file systems.
>


I have no problems (personally) about allowing the different products
to select different default filesystems. The reason people choose
different filesystems is to serve different workloads, so I think this
is just an extension of that.


> Also, as has already been pointed out: there are Fedora systems
> out there using ext4, xfs, btrfs and probably a few other file
> systems today. If we now suddenly change track and consider btrfs
> not 'safe enough', wasn't it pretty irresponsible of us to let
> people use it for their installations ?
>


I think we're saying "it's not stable enough for the *default*".
That's a different statement from "it's not stable enough for use".


> For the workstation, I think the options are
>
> - switch to btrfs soon to give it the exposure it needs to get
> ready (while being careful to limit the supported features, as suse
> does)
>

I'm slightly in favor of this for the Workstation, personally. Without
wide adoption, btrfs will never get any better.


> - stick with ext4 until we have some user-visible features (time
> slider...) that make a switch to btrfs very attractive
>

Certainly an acceptable answer as well. I don't really see any
compelling arguments for XFS in this workload.

[Josh Boyer]

On Wed, Feb 26, 2014 at 12:44 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/26/2014 11:42 AM, Matthias Clasen wrote:
>>
>> On Wed, 2014-02-26 at 11:14 -0500, Matthew Miller wrote:
>>> On Wed, Feb 26, 2014 at 02:59:00PM +0000, Colin Walters wrote:
>>>>> Yeah, agreed here. Everyone wants the latest shiniest thing,
>>>>> even if that thing isn't ready. I really don't want to wade
>>>>> through tons of bug reports for btrfs just because it has a
>>>>> lot of hype.
>>>> Also, right now cloud is plain old ext4. Let's see if we can
>>>> ship *all* of the filesystems! It'll be fun!
>>>
>>> Cloud could switch to XFS along with server. The main problem is
>>> that it'd make us revisit booting -- either 1) some work into
>>> lightening up grub2, 2) testing and possibly enhancing syslinux's
>>> xfs support, or 3) a separate /boot with a different filesystem.
>>> I don't really love any of those options.
>>
>> I'm always dubious of 'there shall be only one' decrees - be it
>> installers or desktop environments or file systems.
>>
>
>
> I have no problems (personally) about allowing the different products
> to select different default filesystems. The reason people choose
> different filesystems is to serve different workloads, so I think this
> is just an extension of that.
>
>
>> Also, as has already been pointed out: there are Fedora systems
>> out there using ext4, xfs, btrfs and probably a few other file
>> systems today. If we now suddenly change track and consider btrfs
>> not 'safe enough', wasn't it pretty irresponsible of us to let
>> people use it for their installations ?
>>
>
>
> I think we're saying "it's not stable enough for the *default*".
> That's a different statement from "it's not stable enough for use".
>
>
>> For the workstation, I think the options are
>>
>> - switch to btrfs soon to give it the exposure it needs to get
>> ready (while being careful to limit the supported features, as suse
>> does)
>>
>
> I'm slightly in favor of this for the Workstation, personally. Without
> wide adoption, btrfs will never get any better.

No, that isn't true. Without wide adoption you may not have any
impetus for btrfs to get better. However, it getting better is
dependent upon wider development, maintenance, and testing. I'm not
sure we are in a position to actually do that, and that is the bulk of
my hesitation. Throwing something upon Fedora users as a default with
the hopes that it will improve is pretty horrible in my opinion,
particularly if we aren't able to actually fix things they find.

josh

[Rahul Sundaram]

Hi


On Wed, Feb 26, 2014 at 1:00 PM, Josh Boyer wrote:

> No, that isn't true. Without wide adoption you may not have any
> impetus for btrfs to get better. However, it getting better is
> dependent upon wider development, maintenance, and testing. I'm not
> sure we are in a position to actually do that, and that is the bulk of
> my hesitation. Throwing something upon Fedora users as a default with
> the hopes that it will improve is pretty horrible in my opinion,
> particularly if we aren't able to actually fix things they find.
>

Does Fedora or more specifically Red Hat have anyone working on Btrfs
upstream that can help guide the path forward? It can't be possibly be the
right decision to let Btrfs be struck in the current position for too long.

Rahul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/f39fcb89/attachment-0001.html>

[Tim Ski]

Does Red Hat provide support for Fedora? If not then in my opinion btrfs
would be a great use case for Fedora to push upstream to RHEL. With XFS
defaulting in RHEL 7 that's cool so I think we should be ahead of the curve
not an Ubuntu competitor or a glorified RHEL release. Like I said in my
opinion.
On Feb 26, 2014 1:08 PM, "Rahul Sundaram" <metherid at gmail.com> wrote:

> Hi
>
>
> On Wed, Feb 26, 2014 at 1:00 PM, Josh Boyer wrote:
>
>> No, that isn't true. Without wide adoption you may not have any
>> impetus for btrfs to get better. However, it getting better is
>> dependent upon wider development, maintenance, and testing. I'm not
>> sure we are in a position to actually do that, and that is the bulk of
>> my hesitation. Throwing something upon Fedora users as a default with
>> the hopes that it will improve is pretty horrible in my opinion,
>> particularly if we aren't able to actually fix things they find.
>>
>
> Does Fedora or more specifically Red Hat have anyone working on Btrfs
> upstream that can help guide the path forward? It can't be possibly be the
> right decision to let Btrfs be struck in the current position for too long.
>
> Rahul
>
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/88ac409b/attachment.html>

[Josh Boyer]

On Wed, Feb 26, 2014 at 1:08 PM, Rahul Sundaram <metherid at gmail.com> wrote:
> Hi
>
>
> On Wed, Feb 26, 2014 at 1:00 PM, Josh Boyer wrote:
>>
>> No, that isn't true. Without wide adoption you may not have any
>> impetus for btrfs to get better. However, it getting better is
>> dependent upon wider development, maintenance, and testing. I'm not
>> sure we are in a position to actually do that, and that is the bulk of
>> my hesitation. Throwing something upon Fedora users as a default with
>> the hopes that it will improve is pretty horrible in my opinion,
>> particularly if we aren't able to actually fix things they find.
>
>
> Does Fedora or more specifically Red Hat have anyone working on Btrfs
> upstream that can help guide the path forward? It can't be possibly be the
> right decision to let Btrfs be struck in the current position for too long.

Fedora is harder to quantify because of the community aspect. I can
say that there is nobody on the Fedora Engineering Team (which the
Fedora kernel team is a part of) that is working on btrfs upstream.
We do have Fedora contributors like Chris Murphy and others who have
been doing a lot of testing and bug reporting around btrfs for a while
though.

I have less insight as to broader Red Hat involvement. Btrfs is a
tech preview in the RHEL7 Beta, so some level of participation is to
be expected. How much that translates to upstream development is
unclear.

josh

[Adam Williamson]

On Wed, 2014-02-26 at 14:05 -0500, Josh Boyer wrote:

> I have less insight as to broader Red Hat involvement. Btrfs is a

IIRC RH employed one or two of the primary btrfs devs for a while, but
we don't any more. I want to say one of them is working at Facebook now,
but I'm not 100% sure.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Tomasz Torcz]

On Wed, Feb 26, 2014 at 11:37:58AM -0800, Adam Williamson wrote:
> On Wed, 2014-02-26 at 14:05 -0500, Josh Boyer wrote:
>
> > I have less insight as to broader Red Hat involvement. Btrfs is a
>
> IIRC RH employed one or two of the primary btrfs devs for a while, but
> we don't any more. I want to say one of them is working at Facebook now,
> but I'm not 100% sure.

Both are at FB (Chris and Josef).

--
Tomasz Torcz Only gods can safely risk perfection,
xmpp: zdzichubg at chrome.pl it's a dangerous thing for a man. -- Alia

[Stephen John Smoogen]

On 26 February 2014 11:08, Rahul Sundaram <metherid at gmail.com> wrote:

> Hi
>
>
> On Wed, Feb 26, 2014 at 1:00 PM, Josh Boyer wrote:
>
>> No, that isn't true. Without wide adoption you may not have any
>> impetus for btrfs to get better. However, it getting better is
>> dependent upon wider development, maintenance, and testing. I'm not
>> sure we are in a position to actually do that, and that is the bulk of
>> my hesitation. Throwing something upon Fedora users as a default with
>> the hopes that it will improve is pretty horrible in my opinion,
>> particularly if we aren't able to actually fix things they find.
>>
>
> Does Fedora or more specifically Red Hat have anyone working on Btrfs
> upstream that can help guide the path forward? It can't be possibly be the
> right decision to let Btrfs be struck in the current position for too long.
>
>
It isn't stuck. It is just moving slowly. Remember when btrfs first came
out and the older filesystem guys said it could take up to 10 years to get
it ready? And a lot of people said it won't take that long... Well it turns
out that filesystems are very very hard to get right and corner cases are
machine bricking versus crash and reboot. Those corner cases get found by
people bricking their systems which means you have to be ready to say "Hey
I don't need this enterprise box and its data.... let me throw my workload
at it." which is a small subset of users out there. That means progress is
slow and painful.



> Rahul
>
> _______________________________________________
> server mailing list
> server at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/server
>



--
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/b7035a10/attachment.html>

[Josh Boyer]

On Tue, Feb 25, 2014 at 5:53 PM, Chris Murphy <lists at colorremedies.com> wrote:
> adding desktop@ since they are also looking at file system options
>
> On Feb 25, 2014, at 1:42 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
>
>>> === File system ===
>>>
>>> The default file system type for workstation installs should be
>>> btrfs.
>>
>> The default file system is definitely up for some debate, but I'd make
>> an argument for using XFS atop LVM[1] for the default filesystem in
>> the Fedora Server, at least in part because Red Hat's storage experts
>> have done the research for us already and determined that XFS is the
>> recommended fit for Red Hat Enterprise Linux 7.
>
> XFS is a really good idea for Server.

I've yet to actually advocate against this majorly, but I'm pretty
against using btrfs as the default for any product. At least in the
F21 timeframe. It's simply not ready.

> Follow-up questions:
>
> - Can Server and Workstation WG's choose different defaults for their product's installers?
>
> - Other than lack of shrink support in XFS, I'd say XFS is suitable for Workstation as well. Would the Workstation WG have concerns about the lack of fs shrink support in the default file system? [1]

I don't think shrink support is a factor at all for Workstation.

>> Btrfs still makes me somewhat nervous, given that its upstream doesn't
>> consider it stable[3].
>
> That wiki entry appears old. The stable aspect was about disk format, which is now stable. And also the experimental description was removed in kernel 3.13. [2]
>
> My main two concerns with Btrfs:
> 1. With even minor problems users sometimes go straight to the big hammer approach with "btrfsck/btrfs check --repair" rather than the recommended approaches. Remounting with -o recovery, and even using a newer kernel are recommended on linux-btrfs@ significantly more often than btrfs check --repair.

That's a pretty poor user experience either way. The filesystem
should be the last thing the user has to worry about, and forcing them
to upgrade to get their FS fixed is indicative of btrfs not being
ready.

> 2. Supporting multiple device volumes in Anaconda. Although multiple device Btrfs volumes work very well when devices are working, there's no device failure notification yet. When a device fails, the volume becomes read-only; and the volume isn't mountable (or bootable) without the use of "degraded" mount option. While this can be done as a boot parameter, it's sort of a non-obvious thing for the typical user. I think it's valid for either WG to consider reducing exposure by dropping Anaconda support for it, or placarding the feature somehow.

If, and it's a very big if, Workstation were to go with btrfs, I would
really push for a reduced functionality mode similar to what OpenSUSE
is doing. No RAID, no multi-device, etc.

josh

[Chris Murphy]

On Feb 26, 2014, at 8:13 AM, Michael Cronenworth <mike at cchtml.com> wrote:
> Ext4 has its btrfs conversion tool. Changing from ext4 to XFS, for arguably negligible benefits for Workstations, will make it more difficult for Fedora users to transition to btrfs.

It's an unlikely path because a.) by default we put ext4 on LVM; b.) the convert tool uses ext4 block size to set btrfs leaf size; c.) the convert tool doesn't set extref, although it easily could. The last two are a cake walk to change compared to the first.


On Feb 26, 2014, at 8:20 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:

> I agree switching from ext4 to XFS is likely not worthwhile.

Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for Workstation WG to mimic it merely due to simplicity because then we don't need separate installers or composes.



On Feb 26, 2014, at 8:24 AM, David Cantrell <dcantrell at redhat.com> wrote:
>
> I think filesystem variance across different Fedoras really impacts QA more
> than us. We already support a lot of filesystems, but the real hit is the
> QA test matrix.

QA already tests the file system layouts being discussed. Perhaps the least tested is XFS on LVM only because the XFS test case doesn't specify LVM, so testers probably split and do some plain partition and some on LVM.

If Server WG decides on XFS, it effectively increases the Automatic/Guided/easy/default installer path's "Partition Scheme" pop-up from four to five options, and that is a problem. Adamw and I are working on a proposal to reduce these options to one or two: i.e. a WG chosen product specific default, and maybe "one other" which is decided by Base WG or FESCo.



Chris Murphy

[Adam Williamson]

On Wed, 2014-02-26 at 12:18 -0700, Chris Murphy wrote:

> > I agree switching from ext4 to XFS is likely not worthwhile.
>
> Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for
> Workstation WG to mimic it merely due to simplicity because then we
> don't need separate installers or composes.

I'm broadly in agreement with Chris here. I don't see that any 'plain
partition' filesystem has such a huge difference to the other that it
makes much sense for us to have two products using 'plain partition'
filesystems, by default, but *different* ones.

Choosing btrfs by default is a controversial option, but it's at least
clearly one with very different results from picking a 'plain partition'
filesystem (whether backed by LVM or not). I don't really see the point
in having ext4 for one and xfs for the other. If the only argument for
desktop to keep ext4 if server goes xfs is 'btrfs conversion!', I'm with
cmurf that that's not a compelling argument at all.

The elephant in the room here seems to be LVM backing, I don't see
anyone discussing that. Do desktop and server want to keep LVM backing
by default if they don't go with btrfs? Do desktop and server have
*differing* perspectives there? (Do we want to re-run the Fedora 18 tape
where we switch to no LVM backing by default and then have to go back to
LVM by default for some reason I've forgotten?)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Simo Sorce]

On Wed, 2014-02-26 at 11:42 -0800, Adam Williamson wrote:
> The elephant in the room here seems to be LVM backing, I don't see
> anyone discussing that. Do desktop and server want to keep LVM backing
> by default if they don't go with btrfs? Do desktop and server have
> *differing* perspectives there? (Do we want to re-run the Fedora 18 tape
> where we switch to no LVM backing by default and then have to go back to
> LVM by default for some reason I've forgotten?)

I can only speak from personal experience here, but I always use LVM on
servers and that has served me extremely well. I also always use XFS for
servers on which I store data.

LVM has been fundamental many times to be able to add more disks to my
server w/o long downtime, and even replacing disks with bigger ones
again w/o (or reduced) downtime.

I think this is a pretty important feature for a Server OS.

Copying TBs of data can take quite some time, and being forced to do
that while keeping the server offline because there is no LVM layer to
automatically move all the blocks really sucks.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

[Josh Boyer]

On Wed, Feb 26, 2014 at 2:42 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Wed, 2014-02-26 at 12:18 -0700, Chris Murphy wrote:
>
>> > I agree switching from ext4 to XFS is likely not worthwhile.
>>
>> Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for
>> Workstation WG to mimic it merely due to simplicity because then we
>> don't need separate installers or composes.
>
> I'm broadly in agreement with Chris here. I don't see that any 'plain
> partition' filesystem has such a huge difference to the other that it
> makes much sense for us to have two products using 'plain partition'
> filesystems, by default, but *different* ones.

So my answer was primarily under the premise of Workstation alone. If
Server switches to XFS, then yeah maybe using XFS on Workstation makes
more sense. If Server doesn't, then there's really no benefit to
Workstation doing that. I think we're in violent agreement on this,
so we can stop emailing about it now.

> The elephant in the room here seems to be LVM backing, I don't see
> anyone discussing that. Do desktop and server want to keep LVM backing
> by default if they don't go with btrfs? Do desktop and server have
> *differing* perspectives there? (Do we want to re-run the Fedora 18 tape
> where we switch to no LVM backing by default and then have to go back to
> LVM by default for some reason I've forgotten?)

I'm not sure on the Workstation front. The dm-thinp stuff might be a
solution to some of the snapshotting features btrfs would provide, but
I think that doesn't necessitate LVM thinp. (IIRC, Alexander Larsson
found raw dm-thinp to be more usable and performant for his Docker
stuff too.) It's something we'll have to take up within the WG.

josh

[Stephen Gallagher]

On 02/26/2014 02:42 PM, Adam Williamson wrote:
> On Wed, 2014-02-26 at 12:18 -0700, Chris Murphy wrote:
>
>>> I agree switching from ext4 to XFS is likely not worthwhile.
>>
>> Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile
>> for Workstation WG to mimic it merely due to simplicity because
>> then we don't need separate installers or composes.
>
> I'm broadly in agreement with Chris here. I don't see that any
> 'plain partition' filesystem has such a huge difference to the
> other that it makes much sense for us to have two products using
> 'plain partition' filesystems, by default, but *different* ones.
>
> Choosing btrfs by default is a controversial option, but it's at
> least clearly one with very different results from picking a 'plain
> partition' filesystem (whether backed by LVM or not). I don't
> really see the point in having ext4 for one and xfs for the other.
> If the only argument for desktop to keep ext4 if server goes xfs is
> 'btrfs conversion!', I'm with cmurf that that's not a compelling
> argument at all.
>
> The elephant in the room here seems to be LVM backing, I don't see
> anyone discussing that. Do desktop and server want to keep LVM
> backing by default if they don't go with btrfs? Do desktop and
> server have *differing* perspectives there? (Do we want to re-run
> the Fedora 18 tape where we switch to no LVM backing by default and
> then have to go back to LVM by default for some reason I've
> forgotten?)
>

I can only speak for myself, but regardless of whether Server picks
ext4 or XFS, I think we definitely want it to be on LVM. (LVM
thin-provisioning is another can of worms, but let's talk about that
separately).

[Chris Murphy]

On Feb 26, 2014, at 7:24 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:

> On Tue, Feb 25, 2014 at 5:53 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>
>> XFS is a really good idea for Server.
>
> I've yet to actually advocate against this majorly, but I'm pretty
> against using btrfs as the default for any product. At least in the
> F21 timeframe. It's simply not ready.

Jolla/Sailfish OS use it on mobile phones; openSUSE also considers it ready for their next release, in approximately the same time frame as Fedora 21. Btrfs has been offered as an guided partition path option since Fedora 18. It's been visible in the UI since Fedora 14 or 15. It was first proposed as a default for Fedora 16.

I think the WG's need to have some metric by which to make a largely objective decision, and should get their questions/concerns addressed directly from Btrfs developers if they're considering it as a default.

A certain subjectivity is reasonable too, for example whether Fedora Workstation and Server should be biased more toward production/stability, or development/testing than prior Fedoras. I think answering the bias question makes the file system decision more easily fall into place.

Cloud, I think they probably want to stick it out with plain partition ext4 due to booting simplicity.



>> My main two concerns with Btrfs:
>> 1. With even minor problems users sometimes go straight to the big hammer approach with "btrfsck/btrfs check --repair" rather than the recommended approaches. Remounting with -o recovery, and even using a newer kernel are recommended on linux-btrfs@ significantly more often than btrfs check --repair.
>
> That's a pretty poor user experience either way. The filesystem
> should be the last thing the user has to worry about, and forcing them
> to upgrade to get their FS fixed is indicative of btrfs not being
> ready.

The same recommendation happens on the XFS list too when people having file system problems have old kernels and repair tools. Btrfs is young, and an "old" kernel is maybe only 6-9 months old. Fedora kernels are kept exceptionally current, as are the btrfs user space tools which is likely why fewer Fedora users have Btrfs problems compared to distributions that use much older kernels.

Somewhat less often than users immediately trying btrfsck --repair, are users on the XFS list who report having used xfs_repair -L right after a crash instead of first mounting the file system. That's rather damaging too. The offline repair check/repair utility as the first step after a crash is obsolete 10 years ago, yet people still do such things.

The reality is that the repair tool fixes edge cases, because the file system is designed to not really need one. The common problems either don't happen in the first place, are fixed on a normal mount, or are fixed with the recovery mount option.

My suggestion for the Workstation WG is find out if btrfsck --repair is too often causing worse problem. I don't know the answer to that, but I think it needs to be put directly to Btrfs developers. Any other source is just an anecdote.


>> 2. Supporting multiple device volumes in Anaconda. Although multiple device Btrfs volumes work very well when devices are working, there's no device failure notification yet. When a device fails, the volume becomes read-only; and the volume isn't mountable (or bootable) without the use of "degraded" mount option. While this can be done as a boot parameter, it's sort of a non-obvious thing for the typical user. I think it's valid for either WG to consider reducing exposure by dropping Anaconda support for it, or placarding the feature somehow.
>
> If, and it's a very big if, Workstation were to go with btrfs, I would
> really push for a reduced functionality mode similar to what OpenSUSE
> is doing. No RAID, no multi-device, etc.

I agree, but to some degree this is up to the WG's and anaconda folks to work out. Today if a user chooses 2+ disks, and the default/Automatic/guided installation path with Partition Scheme set to Btrfs, those drives have data profile raid0, and metadata profile raid1. It's been this way for a while. So what you're suggesting is a change at least to the automatic/easy path for Btrfs, and possibly also a change for Manual/custom, and reads like a distinct shift in bias of Fedora.next to something more production/stability oriented than past Fedoras.


Chris Murphy

[Josh Boyer]

On Wed, Feb 26, 2014 at 3:32 PM, Chris Murphy <lists at colorremedies.com> wrote:
>
> On Feb 26, 2014, at 7:24 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
>
>> On Tue, Feb 25, 2014 at 5:53 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>>
>>> XFS is a really good idea for Server.
>>
>> I've yet to actually advocate against this majorly, but I'm pretty
>> against using btrfs as the default for any product. At least in the
>> F21 timeframe. It's simply not ready.
>
> Jolla/Sailfish OS use it on mobile phones; openSUSE also considers it ready for their next release, in approximately the same time frame as Fedora 21. Btrfs has been offered as an guided partition path option since Fedora 18. It's been visible in the UI since Fedora 14 or 15. It was first proposed as a default for Fedora 16.

All true. (Though for clarity, OpenSUSE is offering a reduced feature
mode by default.)

> I think the WG's need to have some metric by which to make a largely objective decision, and should get their questions/concerns addressed directly from Btrfs developers if they're considering it as a default.

I've discussed some of this with the FS team within Red Hat. I'm
hoping to draw them out of hiding, and I hope they come with data.

> A certain subjectivity is reasonable too, for example whether Fedora Workstation and Server should be biased more toward production/stability, or development/testing than prior Fedoras. I think answering the bias question makes the file system decision more easily fall into place.

Yes, seems fair.

> Cloud, I think they probably want to stick it out with plain partition ext4 due to booting simplicity.
>
>
>
>>> My main two concerns with Btrfs:
>>> 1. With even minor problems users sometimes go straight to the big hammer approach with "btrfsck/btrfs check --repair" rather than the recommended approaches. Remounting with -o recovery, and even using a newer kernel are recommended on linux-btrfs@ significantly more often than btrfs check --repair.
>>
>> That's a pretty poor user experience either way. The filesystem
>> should be the last thing the user has to worry about, and forcing them
>> to upgrade to get their FS fixed is indicative of btrfs not being
>> ready.
>
> The same recommendation happens on the XFS list too when people having file system problems have old kernels and repair tools. Btrfs is young, and an "old" kernel is maybe only 6-9 months old.

"Young." 7 years is not young when it comes to having repair and
recovery tools, or surviving things like ENOSPC. I realize _those_
things in btrfs-land actually are young, but that is kind of providing
some of the hesitation on my side. It took them this long to have
those basic features available? How long will it take them to have it
so that the corner cases don't break?

>Fedora kernels are kept exceptionally current, as are the btrfs user space tools which is likely why fewer Fedora users have Btrfs problems compared to distributions that use much older kernels.

mmm... I have no way to compare against other distributions. I'm glad
Fedora is perceived as having better Btrfs support, but I can assure
you it isn't because of any concerted effort on our part. However,
when it comes to bug reports for filesystems in Fedora kernels, btrfs
is by far the leading FS over ext4 or XFS. Some of this is due to
age, sure. Most of it is due to sustained effort by a large community
of people for upstream development, and a reduced feature set compared
to btrfs. In sort, btrfs has a lot of catching up to do, and it's
trying to do that while also leapfrogging everything else.

> Somewhat less often than users immediately trying btrfsck --repair, are users on the XFS list who report having used xfs_repair -L right after a crash instead of first mounting the file system. That's rather damaging too. The offline repair check/repair utility as the first step after a crash is obsolete 10 years ago, yet people still do such things.

People do stupid things after an error. Yes. That isn't what I'm
worried about. I'm worried about hitting those errors to begin with.

> The reality is that the repair tool fixes edge cases, because the file system is designed to not really need one. The common problems either don't happen in the first place, are fixed on a normal mount, or are fixed with the recovery mount option.
>
> My suggestion for the Workstation WG is find out if btrfsck --repair is too often causing worse problem. I don't know the answer to that, but I think it needs to be put directly to Btrfs developers. Any other source is just an anecdote.

I think I'd like to see if anything gets discussed at LFS in a month
or so. One of the Fedora kernel team members is going to be around,
so hopefully we can get some more information from multiple sources
involved there.

Also, if btrfsck --repair is a major source of problems, and you have
to ask a developer if you'll lose data if you run it, then is the tool
_really_ ready? I disagree with the assertion that it isn't needed.
The filesystem might be designed to not need one, but either the
design or implementation is lacking enough that it is needed and now
we're left in a fairly _unstable_ state. That is not what I want as a
default FS.

Please don't mistake my hesitation on using it as the default as being
against Btrfs. I'm not. I would love to have it work, work well, and
used as the default. It allows much more ease of use and interesting
features than anything else. I simply do not think it is in a state
where that is a safe choice to make. I do not, as a member of a WG or
a kernel maintainer, want to continually apologize for people losing
data or having unbootable machines because we choose poorly. If we
get data and comparisons that show otherwise, as you suggested, then I
will be very interested in looking at it as default.

>>> 2. Supporting multiple device volumes in Anaconda. Although multiple device Btrfs volumes work very well when devices are working, there's no device failure notification yet. When a device fails, the volume becomes read-only; and the volume isn't mountable (or bootable) without the use of "degraded" mount option. While this can be done as a boot parameter, it's sort of a non-obvious thing for the typical user. I think it's valid for either WG to consider reducing exposure by dropping Anaconda support for it, or placarding the feature somehow.
>>
>> If, and it's a very big if, Workstation were to go with btrfs, I would
>> really push for a reduced functionality mode similar to what OpenSUSE
>> is doing. No RAID, no multi-device, etc.
>
> I agree, but to some degree this is up to the WG's and anaconda folks to work out. Today if a user chooses 2+ disks, and the default/Automatic/guided installation path with Partition Scheme set to Btrfs, those drives have data profile raid0, and metadata profile raid1. It's been this way for a while. So what you're suggesting is a change at least to the automatic/easy path for Btrfs, and possibly also a change for Manual/custom, and reads like a distinct shift in bias of Fedora.next to something more production/stability oriented than past Fedoras.

I agree with what you said here entirely.

I also happen to think that one of the major focus of Workstation is
to produce a _product_ that is more stable than past Fedoras. So
looking at it from that perspective I don't see a reduced feature set
as being that out of line.

josh

[Bill Nottingham]

Kevin Fenzi (kevin at scrye.com) said:
> Another aspect of xfs we may want to investigate and get feedback from
> filesystem folks is how well xfs works on 32bit these days.
>
> RHEL7 doesn't have a 32bit version in their beta, so they only need to
> support 64bit xfs. Does the fact that we expect to have 32bit
> workstation and/or server weigh into this decision any?

We expect to have a 32-bit workstation or server?

Not trying to troll, but I don't know that any of these were specifically
discussed or specified in the products - are there any arches where Fedora
currently exists that we don't necessarily care about having a particular
product on? (For example, if you expand to secondary arches, I'd question
the idea of s390 Workstation.)

Bill, who does have a 32-bit x86 server under his home desk...

[Stephen Gallagher]

On 02/26/2014 04:03 PM, Bill Nottingham wrote:
> Kevin Fenzi (kevin at scrye.com) said:
>> Another aspect of xfs we may want to investigate and get feedback
>> from filesystem folks is how well xfs works on 32bit these days.
>>
>>
>> RHEL7 doesn't have a 32bit version in their beta, so they only
>> need to support 64bit xfs. Does the fact that we expect to have
>> 32bit workstation and/or server weigh into this decision any?
>
> We expect to have a 32-bit workstation or server?
>
> Not trying to troll, but I don't know that any of these were
> specifically discussed or specified in the products - are there any
> arches where Fedora currently exists that we don't necessarily care
> about having a particular product on? (For example, if you expand
> to secondary arches, I'd question the idea of s390 Workstation.)
>
> Bill, who does have a 32-bit x86 server under his home desk...
>

That's one of the topics scheduled to be discussed in the Server
Technical Specification meeting tomorrow. My personal opinion is that
the Server should support any arch defined by FESCo as a "primary
arch", which today would mean 32-bit and 64-bit x86 as well as armv7hl.

[Chris Murphy]

On Feb 26, 2014, at 1:54 PM, Kevin Fenzi <kevin at scrye.com> wrote:

> Another aspect of xfs we may want to investigate and get feedback from
> filesystem folks is how well xfs works on 32bit these days.
>
> RHEL7 doesn't have a 32bit version in their beta, so they only need to
> support 64bit xfs. Does the fact that we expect to have 32bit
> workstation and/or server weigh into this decision any?

I think the only limit is 16TB max file system, so off hand I'd say no. But this also applies to ext4.

I just tested with 3.13.4-200.fc20.i686+PAE.

XFS (sdc): file system too large to be mounted on this system.
EXT4-fs (sdc): filesystem too large to mount safely on this system.

The same 32-bit kernel mounts a 20TB Btrfs volume with no complaints, so I don't know its limit.

http://paste.fedoraproject.org/80784/93470280/

XFS mounts with inode64 by default, same as x86_64. So that's good.


Chris Murphy

[Kevin Fenzi]

On Wed, 26 Feb 2014 21:13:58 -0700
Chris Murphy <lists at colorremedies.com> wrote:

>
> On Feb 26, 2014, at 1:54 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>
> > Another aspect of xfs we may want to investigate and get feedback
> > from filesystem folks is how well xfs works on 32bit these days.
> >
> > RHEL7 doesn't have a 32bit version in their beta, so they only need
> > to support 64bit xfs. Does the fact that we expect to have 32bit
> > workstation and/or server weigh into this decision any?
>
> I think the only limit is 16TB max file system, so off hand I'd say
> no. But this also applies to ext4.
>
> I just tested with 3.13.4-200.fc20.i686+PAE.
>
> XFS (sdc): file system too large to be mounted on this system.
> EXT4-fs (sdc): filesystem too large to mount safely on this system.
>
> The same 32-bit kernel mounts a 20TB Btrfs volume with no complaints,
> so I don't know its limit.
>
> http://paste.fedoraproject.org/80784/93470280/
>
> XFS mounts with inode64 by default, same as x86_64. So that's good.

I wasn't referring to filesystem size limits... there was some issue
with Xfs and linux kernel stacks on 32bit linux causing crashes and
data loss.

I don't know if this has been fixed, no longer applies or just has been
ignored by only using it on 64bit machines, but before we go making it
a default and shipping it on 32bit, we should ask around about it. ;)

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140226/e611616a/attachment.sig>

[Chris Murphy]

On Feb 26, 2014, at 9:41 PM, Kevin Fenzi <kevin at scrye.com> wrote:

> On Wed, 26 Feb 2014 21:13:58 -0700
> Chris Murphy <lists at colorremedies.com> wrote:
>
>>
>> On Feb 26, 2014, at 1:54 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>>
>>> Another aspect of xfs we may want to investigate and get feedback
>>> from filesystem folks is how well xfs works on 32bit these days.
>>>
>>> RHEL7 doesn't have a 32bit version in their beta, so they only need
>>> to support 64bit xfs. Does the fact that we expect to have 32bit
>>> workstation and/or server weigh into this decision any?
>>
>> I think the only limit is 16TB max file system, so off hand I'd say
>> no. But this also applies to ext4.
>>
>> I just tested with 3.13.4-200.fc20.i686+PAE.
>>
>> XFS (sdc): file system too large to be mounted on this system.
>> EXT4-fs (sdc): filesystem too large to mount safely on this system.
>>
>> The same 32-bit kernel mounts a 20TB Btrfs volume with no complaints,
>> so I don't know its limit.
>>
>> http://paste.fedoraproject.org/80784/93470280/
>>
>> XFS mounts with inode64 by default, same as x86_64. So that's good.
>
> I wasn't referring to filesystem size limits... there was some issue
> with Xfs and linux kernel stacks on 32bit linux causing crashes and
> data loss.

Yes I know. Even 32-bit mkfs will make a much bigger file system, it just won't mount it. I'm only finding some things 2+ years old suggesting it was once possible to mount XFS bigger than 16TB on 32bit OS, but after filling it (mounted rw) to just beyond 16TB then the kernel would panic and that was the end of accessing the volume from a 32bit kernel.

inode64 is important even for 32bit because otherwise all the inodes end up in the first 1TB and the whole file system is wonky and slow if it's sufficiently large.

> I don't know if this has been fixed, no longer applies or just has been
> ignored by only using it on 64bit machines, but before we go making it
> a default and shipping it on 32bit, we should ask around about it. ;)

Sure, I agree. I will ask on the XFS list and also include armv7hl in the inquiry even though I'm not certain they are interested in XFS (?).

Chris Murphy

[Chris Murphy]

On Feb 26, 2014, at 10:27 PM, Chris Murphy <lists at colorremedies.com> wrote:
> On Feb 26, 2014, at 9:41 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>
>> I don't know if this has been fixed, no longer applies or just has been
>> ignored by only using it on 64bit machines, but before we go making it
>> a default and shipping it on 32bit, we should ask around about it. ;)
>
> Sure, I agree. I will ask on the XFS list and also include armv7hl in the inquiry even though I'm not certain they are interested in XFS (?).


http://oss.sgi.com/pipermail/xfs/2014-February/034588.html

i686 is regularly tested upstream, and there are no concerns about it being used by default there. I'm a bit less certain about the arm response, so maybe solicit feedback from them in case they have concerns about it?


Chris Murphy

[Matthew Miller]

On Wed, Feb 26, 2014 at 09:41:33PM -0700, Kevin Fenzi wrote:
> I wasn't referring to filesystem size limits... there was some issue
> with Xfs and linux kernel stacks on 32bit linux causing crashes and
> data loss.

Possibly this:
<https://www.redhat.com/archives/nahant-list/2005-June/msg00304.html>

But I too have no idea what's happened on this front in the past nine years.
I suspect quite a lot.

--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>