[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-users
Subject:    Re: [qubes-users] Password-less KDM login
From:       David Hobach <tripleh () nurfuerspam ! de>
Date:       2015-02-22 17:42:22
Message-ID: 54EA14FE.8090902 () nurfuerspam ! de
[Download RAW message or body]


On 22.02.2015 18:11, george wrote:
> 
> On 22/02/15 12:35, Marek Marczykowski-Górecki wrote:
> > On Sun, Feb 22, 2015 at 12:22:56PM +0100, David Hobach wrote:
> > > On 21.02.2015 14:01, Marek Marczykowski-Górecki wrote:
> > > > On Sat, Feb 21, 2015 at 01:24:58PM +0100, David Hobach wrote:
> > > > > Dear users,
> > > > > 
> > > > > does anyone know how to disable the password prompt by KDM in dom0?
> > > > > 
> > > > > System Settings -> Login Screen -> Convenience changes had no effect.
> > > > 
> > > > If you've installed KDE+Xfce4, then your login manager is lightdm and
> > > > autologin can be configured in /etc/lightdm/lightdm.conf.
> > > 
> > > Thanks a lot Marek, that did the job!
> > > 
> > > For reference:
> > > In /etc/lightdm/lightdm.conf under [SeatDefaults] (not where the
> > > documentation is written down)
> > > autologin-user=[user]
> > > autologin-user-timeout=0
> > > 
> > > > > Honestly I don't understand the decision of having it enabled by
> > > > > default in
> > > > > Qubes as it does not bring any value from a security point of view -
> > > > > especially for a single user OS such as Qubes (the only use case I
> > > > > currently
> > > > > see is the user leaving his desk after typing in his luks
> > > > > password). It just
> > > > > costs time during the boot process.
> > > > 
> > > > Theoretically you can choose to install system with no disk encryption,
> > > > in case of physically protected computer case (padlock, safe box,
> > > > etc) it
> > > > can make sense.
> > > 
> > > I see your point. So in a perfect world there'd be some checkbox during
> > > Qubes installation. ;-)
> > > 
> > > Btw a low prio Qubes VM Manager bug I noticed:
> > > If you have the VM Manager in autostart and the dom0 boot + VM
> > > Manager start
> > > process is faster than starting the netvm and firewallvm those two will
> > > always remain in "yellow" state instead of the green one. Apparently a
> > > racing condition/missing VM Manager update. That's not really
> > > important as
> > > long as there were no errors during those VM startup processes, but
> > > rather
> > > annoying otherwise as the user doesn't notice these errors.
> > 
> > Actually this is not manager problem, but fast (auto-)login. Netvm is
> > started asynchronously in the background and if you login before it is
> > started, GUI will do not connect to it. A workaround would be to add
> > some delay in autologin, or in /etc/xdg/autostart/qubes-guid.desktop.
> > 
> I had also noticed this happening but hadn't got round to trying to find
> out why.  I've just been opening a terminal in netvm which turns the
> state to green.  Same thing for firewallvm for me.

The /etc/xdg/autostart/qubes-guid.desktop just worked perfectly with a 
10s delay, thanks.
Actually the code "qvm-run --all true" looks like the already existing 
workaround to update the state (I'd never have guessed that from looking 
at it) similar to what george mentions; so using "sleep 10 && qvm-run 
--all true" certainly doesn't hurt.

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-users" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-users+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-users@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-users/54EA14FE.8090902%40nurfuerspam.de. For \
more options, visit https://groups.google.com/d/optout.


["smime.p7s" (application/pkcs7-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]