server December 2014

server@lists.fedoraproject.org

28 participants
35 discussions

Proposal to CANCEL: Server WG meeting 2014-12-30
by Truong Anh Tuan 30 Dec '14

30 Dec '14

Hi all, Most of us are in holidays and there is no agenda so I propose to cancel today meeting. We can continue discussing on this mailing list. Happy new year. See you. Kind regards, Tuan

2 1

Comment issue with the Server WG Blog
by Stephen Gallagher 26 Dec '14

26 Dec '14

So, a number of people have written to me to let me know that comments don't work on the Server WG blog. I took a look at it today and discovered the following: 1) Logging in with OpenID first seems to allow comments for me. I am unclear on whether that's limited to admin users. 2) Disabling the WP-Spamfree plugin restores functionality. I'm inclined for the time being to just set all comments to moderated and disable the Spamfree plugin. Any opposition?

3 3

Server SIG Weekly Meeting Minutes (2014-12-16)
by Stephen Gallagher 16 Dec '14

16 Dec '14

================================================================= #fedora-meeting: Server SIG Weekly Meeting (2014-12-16) ================================================================= Meeting started by sgallagh at 16:02:57 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-12-16/fedora-meeting.2… . Meeting summary --------------- * roll call (sgallagh, 16:02:57) * Agenda (sgallagh, 16:07:53) * Agenda Item: Database Server Role Design (sgallagh, 16:08:04) * adamw will work on a proposal for defining/documenting server role capabilities and requirements outside of the release criteria (sgallagh, 16:10:46) * Database Server Role Design (sgallagh, 16:15:19) * LINK: https://lists.fedoraproject.org/pipermail/server/2014-December/001694.html (sgallagh, 16:15:57) * rolekit should support creating an admin account when creating the DB, but stay out of user management otherwise (sgallagh, 16:32:09) * AGREED: The Database Server Role will be built with a single local process, with rolekit instances maintaining the databases within it. (lazy consensus) (sgallagh, 16:37:28) * If we select a graphical tool for managing PostgreSQL, it must be able to manage user rights, replication and other system-level tasks (sgallagh, 16:43:54) * A UI for SQL queries is a non-requirement (sgallagh, 16:44:04) * Any UI we employ for the Database Server Role must be integrated with Cockpit in some reasonable way (sgallagh, 16:47:07) * Cantas (sgallagh, 16:54:36) * LINK: http://cantas-fedoraserver.rhcloud.com/ (danofsatx-work, 16:55:26) * LINK: https://github.com/xychu/cantas ? (adamw, 16:56:15) * LINK: https://github.com/onepiecejs/nodejs-cantas (sgallagh, 16:56:24) * Cantas authentication does not integrate with fedoauth (yet) (danofsatx-work, 16:57:55) * Current authentication is only through Google or Kerberos. (danofsatx-work, 16:59:04) * Fedora Infrastructure does not support Kerberos (sgallagh, 16:59:21) Meeting ended at 17:09:01 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * sgallagh (117) * simo (69) * danofsatx-work (27) * adamw (17) * zodbot (12) * hanthana (8) * mclasen (4) * kushal (3) * mizmo (1) * nirik (0) * mitr (0) * stefw (0) * danofsatx (0) * tuanta (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Agenda for 2014-12-16 Server SIG Meeting
by Stephen Gallagher 16 Dec '14

16 Dec '14

Sorry for the late agenda folks. Currently, the only topic on my radar is the Database Server Role. Anything else we should cover? This is probably the last Server SIG meeting this year, as I expect a lot of folks will be on vacation starting next week.

1 0

Fedora Server Trello
by Stephen Gallagher 15 Dec '14

15 Dec '14

In an effort to make Fedora Server fully buzzword-compliant, I have created a Trello organization and board for keeping tabs on the open tasks we need to complete. This will help us visualize what work we want to get done, who is doing it and whether it's blocked. The new board is public and located at https://trello.com/b/Cxf1YFs7/fedora-server and the organization is located at https://trello.com/fedoraserver The purpose of this Trello board is to track those high-level issues that apply to the Fedora Server project as a whole. Tracking of individual project-level implementation should continue to be done within those projects. I've added a few existing tasks that we have on our plate. Members of the Server SIG: if you're interested in following along (and ideally picking up and working on a few tasks), please create a Trello account and email me with your ID so that I can add you to the organization. If you are sitting on the Server WG, please consider this to be strongly encouraged.

6 7

Database Server Role Design Considerations (Take Two)
by Stephen Gallagher 15 Dec '14

15 Dec '14

Intentionally breaking the thread here. I realize that my initial email made a lot of assumptions, so I'm going to try to take this back to the drawing board and have us identify the goals of the Database Server before we attempt to define an implementation. So first let's agree on the intention here: the purpose of a Database Server Role is to provide a place for end-users to store data in an SQL-compliant format. We (the Server SIG) consider this to be core infrastructure functionality that will be needed by many (nee. most) applications deployed in a user's environment. Requirements from a user perspective: * I must be able to create one or more databases for my applications * I must be able to set up users with some level of privilege for the individual databases * My database must be able to speak some dialect of SQL * I want to be able to use the same Fedora machine/VM for running multiple databases * I want to be able to replicate my databases between Fedora machines * I want to have regular, automated backups of my databases. By its very nature, PostgreSQL (and MariaDB and many others) can support multiple databases running inside of a single service on a system. One common approach to reducing resources is to host several such databases on one physical or virtual machine (or cluster of machines), rather than assuming the overhead of running an additional operating system to host the database server. On the other side of this, there are those who prefer to isolate their databases entirely from one another, so that a flaw found in one cannot escalate to revealing data about the others. There are generally two approaches that people take to this these days. The most secure one is to run the database on separate physical or virtual hardware. The second, more recent approach is to run on the same node but inside a different container environment (such as Docker or rocket). This approach has its own advantages and disadvantages. When we designed rolekit, we designed it to have the concept of role "instances". Our first role, the Domain Controller, allows only a single instance at present (because it really doesn't make sense to run more than one Domain Controller on a single machine). However, as we see above, it *may* in fact make sense to run multiple instances of the Database Server Role through rolekit. There are several potential approaches we could take: 1. We run a single database service on the local machine, using PostgreSQL's built-in functionality. The first time a Database Server Role is deployed on the system, it sets up the service and then creates a rolekit instance associated with the specific database on the server. This rolekit settings associated with this instance will apply to that database only. The difficulty of this approach is that rolekit will not be able to start or stop the instances of the database separately. We will need to start or stop them all together. 2. We run a single database service on the local machine with multiple databases as above, but instead of using rolekit's instancing technology, we treat it as a single role, with more complicated deploy/redeploy settings that controls all databases running on the system. This approach works around the start/stop issue above, but it makes it more difficult to apply settings (and creating a new database results in a redeploy call, which would seem like an odd user experience). 3. We run multiple database services in individual containers on the system. Each of these services is provided by a rolekit instance and is a full, isolated copy of the PostgreSQL processes. Each of these databases will need to operate on a separate port (or the same port on separate interfaces, etc.) 4. We run multiple database services in individual Fedora Cloud VMs that we spin up and kickstart into being and manage through rolekit (talking to libvirt and OpenLMI on the VM). This is a very complicated approach and will not be feasible in the F22 timeframe. Option 4) above is actually kind of a special-case of 1) and 2) except that we're managing the creation of a new VM (and need to add the OpenLMI remoting capabilities). This might be an interesting project down the road, but I think we can rule it out for Fedora 22 Server, particularly with the slightly-shortened schedule. Option 2) provides a workaround to certain peculiarities of how rolekit works, but I personally don't think that the user-experience trade-off is worthwhile. I'm open to arguments, of course. So, from my perspective, Option 1) and Option 3) are the most interesting. Option 1) is definitely the more traditional approach (and probably easier to get up and running quickly), but Option 3) has a bit of a security advantage at the cost of some additional management difficulty. So this is the part where I end this email and ask for feedback. Thank you for reading this far.

2 2

Database Server Role Design Considerations
by Stephen Gallagher 12 Dec '14

12 Dec '14

I'm looking into designing the plan for the Database Server Role (which the Fedora Server WG previously agreed would be based on PostgreSQL). One of the things we didn't really discuss in the PRD was whether we would have a *requirement* for the Roles to have a GUI/WebUI management console for configuring their services. With the use of Cockpit for our top-level system GUI, I think it makes sense that we would want to be able to have a link within Cockpit's UI that takes us to the Role-specific web-based configuration tool. For the Domain Controller, this link is obvious: it should go to the FreeIPA Web UI. For the Database Server, it's less clear-cut. PostgreSQL upstream does not provide a "blessed" GUI/WebUI configuration tool for managing it. Many exist and are provided by the project's very vibrant community. I think we need to select one of these and consider making it a core part of the Database Server role. A (probably incomplete) list of potential tools are provided at https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools I'd like to recommend that for now we stick with one of the ones that is already included in Fedora and are available via a web browser (not requiring a desktop environment/X server). From a quick search, that probably brings the list down to phpPgAdmin. Does anyone on this list know of an alternative web-based tool that they strongly prefer and would like to see us use (and possibly package, if it's not already in Fedora)? I'd like to nail this down fairly soon. My goal is to finish the design for the Database Server Role before the holidays and spend January implementing it.

6 10

Re: Database Server Role Design Considerations
by Truong Anh Tuan 11 Dec '14

11 Dec '14

----- Original Message ----- > From: "Simo Sorce" <simo(a)redhat.com> > To: "Stephen Gallagher" <sgallagh(a)redhat.com> > Cc: "Server SIG" <server(a)lists.fedoraproject.org> > Sent: Wednesday, December 10, 2014 3:26:54 AM > Subject: Re: Database Server Role Design Considerations > On Tue, 09 Dec 2014 09:50:06 -0500 > Stephen Gallagher <sgallagh(a)redhat.com> wrote: > >> I'm looking into designing the plan for the Database Server Role >> (which the Fedora Server WG previously agreed would be based on >> PostgreSQL). >> >> One of the things we didn't really discuss in the PRD was whether we >> would have a *requirement* for the Roles to have a GUI/WebUI >> management console for configuring their services. > > To be honest, while a Graphical UI of sorts would be nice I think we > shouldn't have a requirement to have a WebUI/GUI to actually manage the > role. > We can allow to optionally install one maybe, but not require one, for > one it would basically disqualify some roles because the great > underlying software has no viable graphical UI, and it would also > annoy admins that do not care for a webUI (unless it is part of the > software on its own) and wants to maintain a small footprint. +1 Simo. I think GUI admin should not be mandatory for roles too. Of course, they could be managed by Cockpit (start/stop/etc.) as usual. This change could encourage people to make their own roles. >> With the use of Cockpit for our top-level system GUI, I think it makes >> sense that we would want to be able to have a link within Cockpit's UI >> that takes us to the Role-specific web-based configuration tool. For >> the Domain Controller, this link is obvious: it should go to the >> FreeIPA Web UI. >> >> For the Database Server, it's less clear-cut. PostgreSQL upstream does >> not provide a "blessed" GUI/WebUI configuration tool for managing it. >> Many exist and are provided by the project's very vibrant community. I >> think we need to select one of these and consider making it a core >> part of the Database Server role. >> >> A (probably incomplete) list of potential tools are provided at >> https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools >> >> I'd like to recommend that for now we stick with one of the ones that >> is already included in Fedora and are available via a web browser (not >> requiring a desktop environment/X server). From a quick search, that >> probably brings the list down to phpPgAdmin. > > I would not like to have phpPgAdmin "forced down my throat" to be > honest. Mostly because of the php dependency which I try to remove on > my servers on abysmal security grounds, but also because I do not think > I would use a webui on the same DB server. +1 too. If it is still mandatory, we should consider another tool,because of not only usability, but also security. <snipped> Kind regards, Tuan

4 3

Fedora 21 Final Release Candidate 5 (RC5) Available Now!
by Adam Williamson 10 Dec '14

10 Dec '14

NOTE: Signing of the RC5 checksums is not yet complete. To be sure we're testing the right bits we should remember to check that the images we test match the signed checksum files once they're available, and of course you can carefully check the TLS certificate of the server when downloading the images. fedup tests may require the --nogpgcheck parameter until the signed .treeinfo file is available. releng will update and close the trac ticket when signing is complete. As per the Fedora 21 schedule [1], Fedora 21 Final Release Candidate 5 (RC5) is now available for testing. The difference between RC5 and RC4 is that the changes to python-blivet and pyparted that were introduced in RC1 to fix bug #1166598 have been reverted, as they were found to cause more serious problems than they fixed. As this change affects the installer, all installation validation tests should be run again. Existing RC4 test results for post-installation tests will be considered valid and transferred into the RC5 result pages; from now on, please do all testing with RC5 images. Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary Ideally, all Alpha, Beta, and Final priority test cases for each of these test pages [2] should pass in order to meet the Final Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 21 Final test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6031 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 2

Server SIG Weekly Meeting Minutes (2014-12-09)
by Stephen Gallagher 09 Dec '14

09 Dec '14

=================================================================== #fedora-meeting-1: Server SIG Weekly Meeting (2014-12-09) =================================================================== Meeting started by sgallagh at 16:05:15 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-09/fedora-meeting… . Meeting summary --------------- * roll call (sgallagh, 16:05:28) * Agenda (sgallagh, 16:08:46) * Agenda Item: Select new WG member (sgallagh, 16:09:09) * Agenda Item: Fedora 22 High-Level Planning (sgallagh, 16:09:19) * Select new WG member (sgallagh, 16:11:04) * Candidate: Dan Callaghan (sgallagh, 16:11:32) * Candidate: Brandon Vincent (sgallagh, 16:11:32) * Candidate: Dan Mossor (sgallagh, 16:11:32) * Candidate: Danishka Navin (sgallagh, 16:11:32) * Candidate: Michael J Wolf (sgallagh, 16:11:32) * Reminder to all candidates: a seat on the Working Group is not required to participate in the Fedora Server SIG (sgallagh, 16:12:30) * LINK: https://fedoraproject.org/wiki/User:Dmossor/ServerWG-persona (danofsatx-kf, 16:35:01) * The Server WG feels that Danishka Navin would be most helpful as a teammate with tuanta at this time. (sgallagh, 16:39:20) * The Server WG looks forward to working with Michael Wolf in the Server SIG, but we feel that there was not enough information in his self-nomination to make a fair determination for a seat on the Working Group. (sgallagh, 16:41:50) * The Server WG looks forward to collaborating with Dan Callaghan, but without a certainty of being able to meet the time-commitment, we will not give him the open seat at this time. (sgallagh, 16:49:16) * AGREED: Dan Mossor (danofsatx) will join the Fedora Server Working Group as a full member (+7, 0, -0) (sgallagh, 17:02:44) * Open Floor (sgallagh, 17:03:35) Meeting ended at 17:04:27 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * sgallagh (103) * simo (39) * omzim (36) * junland (27) * danofsatx-kf (26) * bvincent (23) * danofsatx (17) * tuanta (17) * zodbot (15) * adamw (11) * stefw (9) * nirik (2) * masta (2) * danofsatx-work (1) * mitr (0) * mizmo (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server December 2014