server October 2016

server@lists.fedoraproject.org

24 participants
21 discussions

NFS Role Definition
by Jon Stanley 15 Nov '16

15 Nov '16

I'd like some feedback on a (very early) draft that I have of the document for the NFS role definition (if you'd like edit access, just shoot me an email): https://docs.google.com/document/d/1jLyKsECdHdlKltmHGgf_-iOKj-hj4Qjbh5Zgm7a… How I thought of this was to go from user stories, to technical requirements, and finally to activities to meet those requirements. The actor in all of the user stories in an inexperienced admin - are there other actors that we need to be concerned with? Totally open to feedback here - is this even on the right path?

8 19

Tasks for overseers
by Stephen Gallagher 10 Nov '16

10 Nov '16

At this week's Server SIG meeting, we put a call out for volunteers to oversee various parts of our upcoming deliverables. I'm going to start putting together a document and a presentation for the Fedora Council on this, but I need help from the overseers. Specifically, I'd like each of you to put together a "success" document. What I mean by this is a document that describes how exactly you will define your goals for that project during the next two Fedora milestones (F26 and F27). Essentially, it should be a set of things whose presence or absence is immediately obvious to an observer. For example, he's a very rough first draft of the firewall project: Fedora 25 Deliverables: * Fedora Server ships by default with a firewall that disallows all incoming traffic except that which is necessary to remotely administer the system using the official mechanisms[1]. * Fedora Server provides a local public API to manipulate the firewall. * The API for firewall manipulation is secured and accessible only to administrative users. Fedora 26 Deliverables: * We provide a set of playbook snippets to simplify the setup of firewall rules for the creation of new Server Roles with Ansible. I'd like to have these in the next couple weeks so I can merge them together into a single requirements document and probably Fedora Magazine post. [1] SSH, Cockpit and Ansible

2 2

Fedora Release Tools Demo (Canceled) - Written Status
by Amanda Carter 07 Nov '16

07 Nov '16

Hi folks, due to travel and various obstacles, we're not able to host a recorded demo this month. Instead we've put together a status report that includes some additional highlights we think you might be interested in. If you have feedback and/or think this works well, I'd love to know b/c I think this vehicle covers more information than a demo alone so I might do both in the future if it's worth it. Apologies for missing the actual show and tell - if there's anything you'd like to see specifically, I'm sure we can arrange something. https://fedoraproject.org/wiki/ReleaseEngineering/StatusReport#13SEP2016 -- Amanda Carter

1 2

Cockpit 121
by Stef Walter 31 Oct '16

31 Oct '16

http://cockpit-project.org/blog/cockpit-121.html Cockpit is the modern Linux admin interface. We release regularly. Here are the release notes from version 121. Network Configuration Rollback ------------------------------ NetworkManager now has support in its API for detecting whether a network configuration change broke connectivity to the system. Marius did work so that Cockpit can detect this and have NetworkManager rollback the changes that would have caused a remote admin to be disconnected from the system. This is similar to how a Linux desktop asks you to click in a dialog if you accept the new display configuration. Except in the networking case we can test the connectivity automatically. Demo: https://youtu.be/fNIaDl5UR4Q Change: https://github.com/cockpit-project/cockpit/pull/5069 Debugging info for Javascript and CSS ------------------------------------- Cockpit now ships proper Javascript and CSS debugging "map" files in its cockpit-debuginfo packages. These make it easier to troubleshoot issues and develop code that runs in Cockpit. Change: https://github.com/cockpit-project/cockpit/pull/5191 Debian Branding --------------- Cockpit now shows proper branding when running on Debian, and uses the logo installed on the system on its login screen. Screenshot: http://cockpit-project.org/blog/images/debian-branding.png Change: https://github.com/cockpit-project/cockpit/pull/5240 Fix Kerberos single sign on Debian and Ubuntu --------------------------------------------- Stef fixed Kerberos single sign on Debian and Ubuntu. More changes are coming in the next release including support for use with gssproxy and expanding support for non-Kerberos GSSAPI authentication mechanisms. Change: https://github.com/cockpit-project/cockpit/pull/5227 Get it ------ You can get Cockpit here: http://cockpit-project.org/running.html Cockpit 121 is available in Fedora 25: https://bodhi.fedoraproject.org/updates/cockpit-121-1.fc25 Or download the tarball here: https://github.com/cockpit-project/cockpit/releases/tag/121 Take care, Stef

4 6

Re: Default Firewall in Fedora Server 26
by Subhendu Ghosh 27 Oct '16

27 Oct '16

Another option is to leave the VARIANT same, but introduce a new var like MANAGED= and then key of that for cockpit vs Ansible vs Puppet, etc. On Oct 20, 2016 11:07, "Stephen John Smoogen" <smooge(a)gmail.com> wrote: On 20 October 2016 at 09:37, Major Hayden <major(a)mhtx.net> wrote: > On 10/20/2016 07:32 AM, Stephen Gallagher wrote: >> * Create two variants for use with /etc/os-release such as `VARIANT_ID=server` >> and `VARIANT_ID=server-gui`. This would allow us to deliver a different default >> systemd presets and firewall configuration to the system. If the Cockpit GUI was >> installed later, the administrator would need to explicitly enable >> cockpit.socket and grant firewall permission to allow it as a separate action. > > I lean toward this option because it follows some of the existing processes and it won't create any unexpected firewall changes when the cockpit service is installed or started. For example, if a user installs httpd, they will need to open their own firewall ports after they start the service. > I am going to lean towards this one also because while we can 'assume' that a person installed cockpit-server to have it active, it isn't what most cranky old sysadmins expect. They expect to be able to install a package and then tomorrow or 10 months later set it up and work and not have to worry about it running or changing their security posture by turning on ports and services they didn't realize it would until they read it. If we go with the second option there are some paths which we could do with it. 1. Turned off by default. Put it in the manual that to turn it on you do a systemctl <blah> and it will all start working. 2. Turn on by default and document the hell out of it with "Install this and you will have services started up on your server.. We warned you." > -- > Major Hayden > > > _______________________________________________ > server mailing list -- server(a)lists.fedoraproject.org > To unsubscribe send an email to server-leave(a)lists.fedoraproject.org > -- Stephen J Smoogen. _______________________________________________ server mailing list -- server(a)lists.fedoraproject.org To unsubscribe send an email to server-leave(a)lists.fedoraproject.org

3 6

Apologies for missing the meeting
by Stephen Gallagher 26 Oct '16

26 Oct '16

Everyone is fine. We had a family medical scare yesterday with my youngest. She developed a rash on her face, and due to the fact that she suffers from life-threatening allergies, we treated it as a full-scale emergency. During this time, all thought of this meeting flew from my head. Ultimately, it turned out to be allergy-related but not anaphylaxis and she is doing fine.

2 1

Server SIG Weekly meeting today
by Vinny Valdez 26 Oct '16

26 Oct '16

Hello all, I will be out this week as I am in Barcelona for OpenStack Summit and will likely be attending the evening event at this time. Vinny

3 4

Agenda for Server SIG Weekly Meeting (2016-10-25)
by Stephen Gallagher 25 Oct '16

25 Oct '16

OK, I have one agenda item and it won't require quorum to accomplish: Let's set some high-level requirements around the roles that they should all share. The individual implementations will be different, but some things should be common between them. Let's figure out what those are. All are welcome to attend and provide their input. The meeting is at 1800UTC in #fedora-meeting-1 on Freenode.

2 2

nodejs 6.x on s390x
by Dan Horák 21 Oct '16

21 Oct '16

Hi all, seems we weren't paying enough attention to the nodejs NEWS, but recent version(s) support also s390x. A proof is in http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2380695 with just the ExclusiveArch tag removed in the spec. What should be the next steps? Dan

3 3

Default Firewall in Fedora Server 26
by Stephen Gallagher 20 Oct '16

20 Oct '16

One thing that I thought of while writing up my overseer email was this: We decided a couple weeks ago that the plan for Fedora 26 was to deliver two slightly different versions of Fedora Server: one with a GUI (Cockpit) and one that only included the capability for another Cockpit instance to manage it. This implies that we need two different default firewall configurations; one for Server w/ GUI and one without.[1] I see two ways that we could accomplish this: * Create two variants for use with /etc/os-release such as `VARIANT_ID=server` and `VARIANT_ID=server-gui`. This would allow us to deliver a different default systemd presets and firewall configuration to the system. If the Cockpit GUI was installed later, the administrator would need to explicitly enable cockpit.socket and grant firewall permission to allow it as a separate action. * Create a helper systemd service that would run as a dependency of the cockpit.socket service and open the firewall while that service is running. (This helper could be installed as part of the fedora-release-server package, so it wouldn't take effect on systems that aren't Fedora Server). I'm leaning towards the second one (though I'll probably have to come up with new packaging guidelines for how it would work). My concern with this option is that it *is* a deviation from how Fedora generally handles the installation of services; normally installation and starting them are independent. That said, I think an argument can be made that if someone is installing `cockpit-ws` on a Fedora Server system, we can make an assumption that they intend to use it to manage that system. I don't really like the first option because I'm worried that it will set a precedent that will lead to a combinatorial explosion of variants we need to test. But it *does* give us the option to avoid auto-starting cockpit-ws if we install it later. Other ideas are of course most welcome. [1] This is because Cockpit operates on a non-privileged port (9090) and therefore if we leave this port available by default, there's an opportunity for a user process to claim it.

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server October 2016