2:24 p.m.
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