server September 2014

server@lists.fedoraproject.org

15 participants
28 discussions

Proposed Server release criteria for F21 Beta and Final
by Adam Williamson 02 Oct '14

02 Oct '14

Hi, folks. So, I drew up a rough draft of the Server release criteria for Beta and Final as I suggest they might be. We could kick it around at tomorrow's meeting if desired. Here we go: BETA === Remote logging === It must be possible to forward system logs to a remote system using Server packages. === Firewall configuration === Release-blocking roles must be able to report their status in regard to the system firewall as described in the [[Server/Technical_Specification#Firewall|technical specification]]. === Roles === Release-blocking roles and the supported role configuration interfaces must meet the core functional [[Server/Technical_Specification#Role_Definition_Requirements|Role Definition Requirements]] to the extent that supported roles can be successfully started, stopped, and queried. === Cockpit === ?????? FINAL === Roles === Release-blocking roles and the supported role configuration interfaces must fully meet the [[Server/Technical_Specification#Role_Definition_Requirements|Role Definition Requirements]]. === Cockpit === ?????? You will note first of all the big ?????? for Cockpit. Cockpit's role really isn't terribly well defined in the tech spec or PRD, so it is hard to draft requirements. Is it primarily supposed to be an interface for controlling roles? If so, can we treat it that way in the criteria, and require things from it as regards its job in configuring roles? I think the Role criteria described above would be okay, and at least unambitious enough not to cause huge problems, for F21, but I'm really not that happy with them for the long term. It's obviously not practical to start hardcoding specific requirements for specific roles into the criteria. What I would like instead is to have a little more process on the Product side for Roles. I'd suggest that Roles themselves should have definitions of their expected functionality baked in at the point of creation / approval. These could be split into sections to be required at Alpha, Beta and Final. You could, for instance, expect roles to basically start up and not explode at Alpha, expect them to be broadly 'feature complete' and testable at Beta, and expect them to fully meet their listed functional requirements at Final, just as a quick cut. Here's a very rough mock-up for the "Domain Controller" role as a guide: Alpha ----- The Role must start and stop successfully. When the role is running, a client system must be able to enrol into the FreeIPA domain. Beta ---- When the Role is running, it must be able to enrol and unenrol multiple clients. Client systems must be able to authenticate user accounts via Kerberos. The FreeIPA configuration web UI must be available and allow at least basic configuration of user accounts and permissions. Final ----- Oh, I don't know, I'm running out of ideas, I don't do that much more with my FreeIPA system than is described in Beta. You know better than me! That's why you should be writing this! :) Well, I sort of ran out of steam at the end there, but you kinda get the idea, right? We can set things up appropriately so the release criteria can sensibly call out to them. I'd expect the criteria would just say something like 'Release-blocking roles must meet the functional requirements listed in their definition pages for the Beta milestone' or whatever, with a link to a sensible target from which you could easily find the Role definition pages. I'd be very grateful for feedback on both the proposed criteria for F21, and the idea above. We do need to get the Beta criteria in place ASAP, Beta TC1 is due tomorrow (yes, I know, no rest for the wicked :/) I'll start drafting up test cases ASAP. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 3

Server WG Meeting Minutes (2014-09-30)
by Stephen Gallagher 30 Sep '14

30 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =================================================================== #fedora-meeting-1: Server Working Group Weekly Meeting (2014-09-30) =================================================================== Meeting started by sgallagh at 14:59:45 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-09-30/fedora-meeting… . Meeting summary - --------------- * roll call (sgallagh, 14:59:46) * Agenda (sgallagh, 15:03:09) * Agenda Item: Fedora 21 Release Criteria (sgallagh, 15:03:09) * Fedora 21 Release Criteria (sgallagh, 15:04:36) * ACTION: stefw to discuss with the Cockpit upstream what Beta Criteria they should have (sgallagh, 15:26:08) * adamw's proposed criteria were largely accepted, with some pending additions to Cockpit and the Domain Controller role forthcoming. (sgallagh, 15:31:39) * Open Floor (sgallagh, 15:31:50) Meeting ended at 15:34:21 UTC. Action Items - ------------ * stefw to discuss with the Cockpit upstream what Beta Criteria they should have Action Items, by person - ----------------------- * stefw * stefw to discuss with the Cockpit upstream what Beta Criteria they should have * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * sgallagh (51) * adamw (29) * stefw (8) * nirik (5) * zodbot (3) * mitr (2) * tuanta (1) * simo (1) * davidstrauss (0) * mizmo (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQqzmIACgkQeiVVYja6o6PWDACfXlu5EaRZV3SYthtj9Nh2BIw9 jVgAoIST+ojOWMk2Z8KHKzba8AsP1khX =LCF2 -----END PGP SIGNATURE-----

1 0

"Package sets" release criterion: what to do with it?
by Adam Williamson 29 Sep '14

29 Sep '14

Hi, folks. I'm checking the release criteria again for Fedora.next compatibility, and there's an Alpha criterion with obvious issues: "Package sets When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set. " This was obviously written to the world where we had generic installer images - the DVD, and intentionally-generic netinsts. We do not have those things any more. Do we want to dump this criterion entirely, or is there any of it we would like to keep? For instance, would we consider it 'release blocking' functionality for you to be able to do some/any of the above from the Server and/or Workstation network install images *after configuring the repos manually*? Particularly, the minimal installation? I'm not sure F21 as currently conceived would offer an avenue for doing an interactive minimal installation. Basically, it comes down to: do we want to have a blessed method for doing a network install of KDE and/or minimal? If so, do we want to block releases on it? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 1

2014-10-01 @ 16:00 UTC ** Fedora Blocker Review Meeting
by Mike Ruckman 29 Sep '14

29 Sep '14

# F21 Blocker Review meeting # Date: 2014-10-01 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net It's that time of the week again! Currently there are 14 bugs that need some TLC. Happily, that's 11 less than there were last week, so we might stand a chance of getting through them all in the allotted time. If you want to take a look at the accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist We'll be evaluating these bugs to see if they violate the Beta Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F21 can be found on the wiki [0]. Product specific plans are still being solidified, but that should be sorted quickly. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you Wednesday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org

1 0

[Fedocal] Reminder meeting : Fedora Server Working Group
by Pierre-YvesChibon 29 Sep '14

29 Sep '14

Dear all, You are kindly invited to the meeting: Fedora Server Working Group on 2014-09-30 from 11:00:00 to 12:00:00 US/Eastern At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Weekly meeting to discuss issues and planning for the Fedora Server Product and SIG. More information available at: [http://fedoraproject.org/wiki/Server](http://fedoraproject.org/wiki/Server) Source: https://apps.fedoraproject.org/calendar//meeting/283/

1 0

Server Roles
by John Unland 25 Sep '14

25 Sep '14

>Hi John! >As Fedora Server is a community project driven by whoever is >interested in doing the work, certainly we'd like your help on things. >I want to clarify first that I think you have the wrong idea about >what a "Server Role" is. The idea is for a server role to be a >singular task for the server to perform. A machine may be assigned >multiple roles, but they should be managed individually. >I don't see us having a "Small Business" role, in part because that >implies many different things to many different people. Instead, we'd >be talking more about roles like "Domain Controller", "ownCloud >Services" or "OpenStack Node". >We *do* need to start talking about whether we want a graphical option >for Fedora Server 22. We expressly deferred that decision because our >initial target was focusing on headless systems. >John, would you mind running down the use-cases you have for having a >local graphical login on your servers (as opposed to remote services >like SSH or web-based configuration tools like Ajenti or Cockpit)? Okay, I understand. Well I think you do have a point there. It would kinda break the flow of the list in the installation process (Now thinking about it). However I am just now looking at the chat log of you all talking about having multiple roles in one single physical server (If my context clues are right). I know for the beta and I think the full release you want just the base + essential server roles, and then later down the road your going to define more. How about you leave the essential roles for now that way you will have somewhat have a base to go off of other servers (ownCloud, Round Cube, HPC roles, etc.), BUT create a template so that members of the community can create there own roles and add it to a repo list. Kinda like having the Play Store on Android but for servers. I know you are still in Alpha phase but this is just something to consider, but I digress. As for use-cases, I see it like this: Case 1: Migration of servers. Ex: Server A is a old model so were going to migrate the configuration to the new Server A. (You really have to be there physically there to mess with hardware / networking) Case 2: Install / Remove Hardware. Ex: Faulty RAM / CPU / Hard drive (That is not hotswapable) you want a quick way to identify the server and turn it off from a KVM inside the rack. (Not all company's will have a dedicated machine to SSH or go into a web-browser to configure these things. They may still have KVM's inside there cabinets.) Case 3: Installation of server software (Open Source AND Proprietary). Ex: Bitnami + your appliance, a appliance software stack where you can install it in a VM or locally inside a desktop. However you need to have a GUI to configure / start/stop / view logs to install locally. (They still have there own web interface in a browser but you still need a GUI to install it.) Sidenote: Case 3 ~ When you install Bitnami + your appliance locally it uses the Container feature like Docker so it does not interfere with other configurations in the same server. When I was doing my research at my University, I opted to give the user to use either the Ajenti, because it was a quick overview of your server / services that you were running. AND I wanted to have a configuration / overview control panel locally (That I was going to build in-house) so that you could have more advanced outlook on your server as well as local documentation, Hardware Install / Uninstall Wizard, and some other helpful stuff for the person. Because I figured that a small business didn't have a IT staff so it had to depend on ques from the software logs / messages and the documentation. But you could pretty much run the server from either both or one of them just fine... So those are my cases, hope this was some of help to you. :) John

1 0

Server Roles
by John Unland 25 Sep '14

25 Sep '14

Greetings, I'll cut to the chase. I am doing research on opensource small business server adaptation for my University. I am using Ubuntu as of now with software stack to have a SB infrastructure. However I recently heard that Fedora was releasing there Alpha for Fedora Server. I have already tested it out for myself. Is there anyway that I can somehow work with you all to maybe have a server role for Small Businesses? Below is what I'm using for the server. Lightweight DE: LXDE or Xfce Bitnami applications (DB, ownCloud, openERP, Round Cube, DNS etc.) CUPS for print server Ajenti for a control panel.(Was using this but since F21 is going to use Cockpit then I maybe will switch to that) 1 or 2 concept software control panels that are in the works right now. (TBD) I have already read into your Persona's or "Target Market"(and other documents on the Wiki) and it seems to target people with experience in Linux / Networking stuff like that. So I know my request a little bit out of your scope, but I figured I'd ask to see if I could get this server role into the Alpha, Beta, or Full release. Sorry about the long post. John

2 1

Download
by Omar José Tercero Moreira 24 Sep '14

24 Sep '14

Hello, I would like to know where can i download fedora for server?. and is it free too? Thanks for help,

2 1

2014-09-24 @ 16:00 UTC ** F21 Blocker Review
by Mike Ruckman 23 Sep '14

23 Sep '14

# F21 Blocker Review meeting # Date: 2014-09-24 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net Well now that we've finally kicked Alpha out the door, it's time to do some Beta blocker review. You might think, "Oh, hey - that'll be easy, we just started!" However, you'd be wrong. We've been tracking beta and final blockers as well this whole time :) With that said, we have a total of 25 proposed blockers to go through. So be prepared to get comfortable for the meeting. If you want to take a look at the accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist We'll be evaluating these bugs to see if they violate the Beta Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F21 can be found on the wiki [0]. Product specific plans are still being solidified, but that should be sorted quickly. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org

1 0

Server Working Group Weekly Meeting Minutes (2014-08-19)
by Stephen Gallagher 23 Sep '14

23 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =================================================================== #fedora-meeting-1: Server Working Group Weekly Meeting (2014-08-19) =================================================================== Meeting started by sgallagh at 15:01:08 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-09-23/fedora-meeting… . Meeting summary - --------------- * roll call (sgallagh, 15:01:08) * Agenda (sgallagh, 15:05:40) * Agenda Item: Fedora 21 Beta Planning (sgallagh, 15:05:40) * Agenda Item: Cockpit PolicyKit Rules (sgallagh, 15:05:41) * Cockpit PolicyKit Rules (sgallagh, 15:08:51) * Cockpit would like to ship its own policykit rules (sgallagh, 15:10:02) * Cockpit wants to be able to define permission roles besides membership in the "wheel" group (sgallagh, 15:10:30) * ACTION: stefw to start a conversation on role definition in Cockpit on the mailing list (sgallagh, 15:33:42) * ACTION: sgallagh will create a tracking bug for BZs of interest to the Server WG (sgallagh, 15:33:57) * Future WG meetings will involve a review and status update on any bugs connected to that tracker (sgallagh, 15:34:19) * Fedora 21 Beta Planning (sgallagh, 15:34:38) * First topic: Beta release criteria (sgallagh, 15:34:52) * Open Floor (sgallagh, 15:57:37) Meeting ended at 16:00:53 UTC. Action Items - ------------ * stefw to start a conversation on role definition in Cockpit on the mailing list * sgallagh will create a tracking bug for BZs of interest to the Server WG Action Items, by person - ----------------------- * sgallagh * sgallagh will create a tracking bug for BZs of interest to the Server WG * stefw * stefw to start a conversation on role definition in Cockpit on the mailing list * **UNASSIGNED** * (none) People Present (lines said) - --------------------------- * sgallagh (75) * stefw (47) * adamw (44) * simo (35) * mitr (20) * zodbot (5) * tuanta (3) * danofsatx-work (2) * davidstrauss (2) * davidstrauss_ (1) * nirik (0) * mizmo (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQhmS4ACgkQeiVVYja6o6MoswCgnzpMhPwfaju7UaYUCXFp94i4 HdcAn1jTv3Wjz16XG7Qn+CWIQ0S4a8Oa =WbvH -----END PGP SIGNATURE-----

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server September 2014