-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
thank for the clarification.
Than, well done!
I am looking forward to work on the details :-)
Cheers
Am 10.01.2014 22:07, schrieb Stephen Gallagher:
On 01/10/2014 03:44 PM, Joerg Stephan wrote:
> Hi Stephen,
> i guess i am late :-) so maybe caused by that, while reading
> through the document there are some basic questions in my mind,
> so sorry that i start with some clearification question:
> (you EQUAL all contributors so far)
> When you speak about "Server Roles" you mean the service which
> is provided by the server? Like DNS, so you mean that we need an
> easy/remote/api way of installing a service on an server? Like
> you could do it with puppet or spacewalk or maybe WebYAST in
> SUSE?
Server Roles are a closer match to how Windows Server defines
server roles (i.e. This machine is a domain controller, that one is
an Exchange server, this other one is an IIS webserver, etc.) The
idea would be for us to be able to take some common deployment
patterns and turn them into pre-packaged roles. This would
simultaneously make it easier for more junior administrators to
start deploying things while also encouraging a level of uniformity
in deployment that would be easier to support and update.
> Were is the "base"? I mean the basic server, the naked
> installation like a minimal server. For me, as an administrator
> i like really tiny iso`s which provide a basic installation so
> that i can ran into the loud and noisy server room an install the
> system within some seconds and do the rest via ssh (or something
> else).
Well, there are three things in play here. The first is that the
Base Design Working Group is going to be defining what is the
absolute minimum "Fedora" base system (similar to the 'minimal'
group in Fedora today, but more constrained and with dependencies
cleaned up so it's smaller). The Fedora Server and Fedora Cloud
will be building atop this base.
One of the things we're proposing for the Fedora Server is to be
less of a build-it-yourself environment, though. What we want to
install (through whichever installation mechanism;
DVD/netinstall/amazon image, etc.) should always be the same: the
platform that describes the Fedora Server. This will be essentially
the Base plus the infrastructure pieces necessary to support Server
Role deployment on top of it. This will still be a small and
tightly-controlled base platform, but it may be a bit larger than
today's 'minimal install plus sshd'.
> Than (currently last), i am missing "security". Now a days i
> guess security plays a big role. So maybe we should tell a bit
> about security features we need in this set. Like pre configured
> firewalls, maybe installation sets which open there port on
> firewall side. Or maybe an preferrred backup solution, easy to
> install maybe api triggered like we got it in zabbix to bound
> client and server.
These are things that we have discussed and in most cases they
will fall into either of two categories: "Server Roles" and
"Infrastructure needed to support Server Roles".
These are implementation details and are (in my opinion) topics
for the execution planning rather than the high-level requirements
planning. The purpose of this document is to set out our vision
and goals, not to specify a specific implementation.
I hope this clarifies things a bit.
> So far & Cheers
> Jörg
> Am 10.01.2014 21:05, schrieb Stephen Gallagher:
>> The first deliverable that the Fedora Server Working Group was
>> tasked with was the production of a Product Requirements
>> Document. This document is intended to provide a high-level
>> view of the goals and primary deliverables of the Fedora
>> Server distribution. A great deal of discussion has gone on
>> during the weekly Working Group meetings as well as on the
>> mailing list.
>> At this time, the deadline for the delivery of the PRD is
>> rapidly approaching. Originally it was due to be delivered for
>> ratification on Monday, January 13th, but at the FESCo meeting
>> on Wednesday, it was agreed to delay this deadline by a single
>> week. The primary reason for this delay was so that the Fedora
>> Cloud and Fedora Server groups could have some last discussions
>> about overlap and respective areas of responsibility.
>> This past Tuesday, we had an all-day PRD hackfest in IRC and
>> have come up with a fairly strong draft[1]. It is not yet
>> complete (notably, there remains a FIXME under "Misc.
>> Concerns" and some ambiguity around the Use Cases), but I
>> believe that it is close enough to its final form (as
>> envisioned by those people that have contributed to it), that
>> we should expose this document to the wider world and ask for
>> input before submitting it to the Fedora Engineering Steering
>> Committee and Fedora Advisory Board a week from Monday.
>> Please read through the PRD draft and provide feedback of any
>> sort. If you see that we have missed or misrepresented any of
>> our statements, we would very much like to hear this soon.
>> [1]
>>
https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_D...
>>
>>
> _______________________________________________
>> server mailing list server(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/server
> _______________________________________________ server mailing
> list server(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/server
_______________________________________________ server mailing
list server(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/server
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iQEcBAEBAgAGBQJS0RoSAAoJEMkH+YqO31/BDf0H/iAvxLQu+ZmhW8zEAbX1IGXz
iermDLuShu+A7PhzbUlzL/5mZT7LaIv9ehMA+pgwdI9Q6VpAnDKM0K2a6PMcDeKs
M6Qibvju1gdKH1hr7jbvjPSobETgg7z+bOZbDyjdgYru94e7/mCEMkxUJMmjbv5r
AZ9eOCq969yFiPN7LUsot1gsuPyU6cnpsNBqBfiwDeYfxpzb664oOA3pjOBOEGkK
+KXAfiYYfjueMmnIAQCttaWLaxtPRaceS619FsQyT40GM9LSYRiEVZL9JUSQTG1e
7IbNmT1yxfUGshOyf5Tf05vuClDkjS/PBsatp96GmEGGU8Hj7AV3SrQsPd5EBXk=
=Rx9S
-----END PGP SIGNATURE-----