Wider feedback requested on two changes to our base/core defaults

["Jóhann B. Guðmundsson"]

On 08/21/2013 08:22 PM, Miloslav Trmač wrote:
> On Wed, Aug 21, 2013 at 8:45 PM, "Jóhann B. Guðmundsson"
> <johannbg at gmail.com> wrote:
>> Now for those that are not familiar with our default using the short fqdn it
>> cuts the fqdn at the highest level domain as in the first "dot"  so in the
>> sample case the login and command line promt is shown as "container01".
>>
>> That scalability problem comes immediately apparent when you would create
>> the next container01 for the next second level domain like
>> container01.ackme.com you as an ISP would be hosting, it would be also
>> showing "container01" at the login and command line prompt just begging for
>> administrative mistake and headaches.
> It's not obvious to me that optimizing the default setup for ISPs (who
> have server management as their core business, and will likely do much
> more customization to get a competitive edge) is a good idea, but I'll
> defer to people who actually do such things with containers.

If people do not want our login and command promt default to fqdn of the 
host we should move forward and default it to "pretty hostname" instead 
of using the short hostname anyway.

>
>
>> The other issue I would like to get some comments on is that we default to
>> setting an empty root password which will allow administrators to log into
>> containers as root and set the root password as well as removing few line
>> from spin kickstarts as well being beneficial to the arm community.
> * If the container is supposed to resemble an ordinary operating
> system, with user accounts and ability to use it "from the outside"
> (whether using the console or over the network), then it should also
> not allow just anyone who knows the IP address to connect.  (per
> systemd-nspawn(1), --private-network is not default.)

You create an OS container and run other containers within it ( users, 
system etc ).

> * If the container only sandboxes a separate service, there shouldn't
> be a login process (or, an user session, really) running inside in the
> first place; the tools should just launch a shell (or other tool)
> running within the container, with the authentication happening
> outside the container.
> So, "no".
No what?

And I think you are confusing here OS container with application 
container these are two different container solutions.

>> we leave the users anyway open to bruteforce attacks out of the box without them even knowing that it's happening so it comes as bit of security through obscurity not allowing this in the first place.
> That's equivalent to saying that all passwords are security through
> obscurity, and equally incorrect.

If I was not obvious enough the difference is only in time and if you 
are trying to claim that users dont get cracked after installing fedora 
of the dvd I can tell you here and now that it already has happened and 
that user did not have the faintest idea that a) sshd was running and b) 
someone was trying to "login" to his system he just choice to install 
Gnome of relengs dvd because that instalment gave him more complete 
desktop experience.

Lesson he learned from that experience never to use Fedora again.
Lesson we should have learned was for us deliver identical install and 
usage experience of dvd as the "live" images give users.

JBG