NFS Role Definition
by Jon Stanley
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-hj4Qjbh5Zgm...
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?
7 years
Tasks for overseers
by Stephen Gallagher
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
7 years
Fedora Release Tools Demo (Canceled) - Written Status
by Amanda Carter
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
7 years
Re: Default Firewall in Fedora Server 26
by Subhendu Ghosh
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
7 years, 1 month
Apologies for missing the meeting
by Stephen Gallagher
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.
7 years, 1 month
Server SIG Weekly meeting today
by Vinny Valdez
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
7 years, 1 month
Agenda for Server SIG Weekly Meeting (2016-10-25)
by Stephen Gallagher
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.
7 years, 1 month
Default Firewall in Fedora Server 26
by Stephen Gallagher
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.
7 years, 1 month
