[IMAGE] A13(-WIFI) Debian (now Ubuntu) + xfce flashable (Updated: 08 Mar: R18)

[oldpenguin]

Normally the console root autologin feature is in inittab:

T0:23:respawn:/sbin/getty -L -a root ttyS0 115200 vt102

Just remove the "-a root"

Linaro file-system has this feature enabled by default.

[Ekkehard]

Now I am really confused.  @JohnS, @oldpinguin, are you all running R18, or at least some (maybe newer) Ubuntu version?  I was initially looking for /etc/inittab out of memory back from the days when I thought I knew all that stuff.  But Ubuntu does definitely not have an /etc/inittab anymore.  Therefore, R18 should not have one either - so I don't know where you guys are getting yours from.

Also, I'm afraid I need Ubuntu, as in Debian versions I couldn't get apache with php5 to work right, so going back to a Debian version won't cut it for me, as figuring out how to run apache/php5 under Debian still seems to be more work than fixing the autologin problem in Ubuntu (yes, I also read that "it was decided" that Linaro is having this "feature" enabled by default).

Here's the inittab deal: From 6.10 on, Ubuntu uses upstart to handle starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.  So there is no more /etc/inittab by default.  However, I read that upstart would still honor an /etc/inittab file if it was there.  So, following all three suggestions, I added the line that @oldpenguin suggested (i.e. without the -a root) as the only line in my /etc/inittab file, but it didn't change anything.  This is not horribly surprising, since I want to remove an autologin command from wherever it is lingering, not add anything.

I checked the runlevel, and I am running in runlevel 2, as I should.  So I also checked /etc/rc2.d, as upstart likes to put stuff in /etc/rc{n}.d, where n is the runlevel - nothing in there either that would autologin as root (technically, it is olinuxino with superuser privileges).

Is anybody out there who's currently running R18 and doesn't have the autologin problem, or maybe has even solved it? Or somebody having an idea I haven't tried yet?  I seem to be running out of them soon 

[jwischka]

Let me put a beta image together that is a stock Ubuntu Raring (not Linaro) and PM it to you to see if it works for you - and to see if you're seeing a bug that I'm experiencing in my testing. I'm about to be on a marathon conference call, so it may be a bit before I get it uploaded.

Now I am really confused.  @JohnS, @oldpinguin, are you all running R18, or at least some (maybe newer) Ubuntu version?  I was initially looking for /etc/inittab out of memory back from the days when I thought I knew all that stuff.  But Ubuntu does definitely not have an /etc/inittab anymore.  Therefore, R18 should not have one either - so I don't know where you guys are getting yours from.

Also, I'm afraid I need Ubuntu, as in Debian versions I couldn't get apache with php5 to work right, so going back to a Debian version won't cut it for me, as figuring out how to run apache/php5 under Debian still seems to be more work than fixing the autologin problem in Ubuntu (yes, I also read that "it was decided" that Linaro is having this "feature" enabled by default).

Here's the inittab deal: From 6.10 on, Ubuntu uses upstart to handle starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.  So there is no more /etc/inittab by default.  However, I read that upstart would still honor an /etc/inittab file if it was there.  So, following all three suggestions, I added the line that @oldpenguin suggested (i.e. without the -a root) as the only line in my /etc/inittab file, but it didn't change anything.  This is not horribly surprising, since I want to remove an autologin command from wherever it is lingering, not add anything.

I checked the runlevel, and I am running in runlevel 2, as I should.  So I also checked /etc/rc2.d, as upstart likes to put stuff in /etc/rc{n}.d, where n is the runlevel - nothing in there either that would autologin as root.

Is anybody out there who's currently running R18 and doesn't have the autologin problem, or maybe has even solved it? Or somebody having an idea I haven't tried yet?  I seem to be running out of them soon 

[JohnS]

I'm not using R18

John

[Ekkehard]

Thanks $JohnS - now at least I am less confused 

[aquarat]

Not sure if this is useful but (thanks to oldpenguin) I've got this image working on the A13's nand... I'm hoping it'll be possible to flash the image to the nand on other devices using dd.

[Ekkehard]

@aquarat - "this image" meaning R18?  If so, did you solve the auto-login problem, or not run into it at all?  If you run headless, do you see, in addition to yourself, root logged in when you do a "who"?

@jwischka - I'd be more than happy do help you with any debugging to the full extent of my abilities.  You've done so much for this community, it would be great to give you at least a little bit in return.

[aquarat]

Hi Ekkehard

I realise this is not good security protocol but I usually log into systems like the Pi/A13/etc. as root. I don't bother with sudo on those devices.

I noticed on the LiveSuit image oldpenguin prepp'ed for me that the auto-login feature on ttyS0 was present, but I erased the rootfs in his image and replaced it with a copy of this R18 image (which was running on an SD card at the time).

I'll check now and see if it auto-logs in via ttyS0... I usually disable getty on ttyS0 and use the machine via ssh on wifi.

-update-
Login via ssh isn't automatic.
Login via ttyS0 isn't automatic, but it takes approximately a minute for the login prompt on ttyS0 to appear (the device can be logged into via ssh on wifi long before the ttyS0 login prompt presents).
One user, on tty1 shows as logged in, the user is root. This happens using the headless kernel.

[Ekkehard]

Thanks @aquarat!  When hooking up a monitor and keyboard I come in over tty1,  You come in via a serial port - am I right (hence ttyS0)?  Correct me if I'm wrong.  That would be a little different, but still you don't have root logged in via tty1 if I understand you right.

Disabling getty on the console seems a bit drastic to me, since I need to use it occasionally to do maintenance (for instance on calibre, where I don't think there is a CLI).

Yes, you are right!  It isn't good security protocol to always log in as root on any networked machine    I have it easy, as I am not tempted to do that.  I have so many scripts that require extra manual interaction if they detect that they are run with special privileges.  Maybe I'm a little paranoid, but just because I'm paranoid doesn't mean that they are not after me 

[aquarat]

haha @ Ekkehard / they're after me .

My machine does have root logged in automatically on tty1 (the first on screen terminal)... but I've disabled that getty. When the getty on tty1 is enabled root is automatically logged in after boot.

I use the serial port for debugging but I usually disable the getty on that when everything is working (I sometimes use the serial port for other things).

If this machine was a "server", ie. sharing files or running specialised scripts in an environment that was directly connected to the internet... I wouldn't be doing stuff as root... but because the machine only has one user - me - and it's running behind a firewall and it exists to run an application that doesn't require network connectivity I figure root is acceptable . I run an ODroid machine as a small server in an office (not my office) and that has properly set up user accounts. I also have a Pi in PCExtreme's data center and that also has a properly set up user account which uses key-based auth via ssh.

I also usually move the port for ssh to something higher up for inet-linked machines... like 30022.

Also, my thanks to jwischka for this image!

[Ekkehard]

Aha!!!

When the getty on tty1 is enabled root is automatically logged in after boot.

That is what I was wondering. 

So root being logged in after boot appears to be a systemic issue.  Of course, disabling getty on tty1 will fix the symptom, but it will not solve root cause.  And since I am not only paranoid but also pedantic (I guess), I'm still after finding and solving root cause   At any rate, your help with identifying this is much appreciated!!  It also tells me that I didn't do something really stupid to cause root to be logged in after boot, which still makes me feel good, in spite of all the paranoia and pedantry

[aquarat]

There's a script : /bin/auto-root-login
which logs root in.

It is referred to in /etc/init/openvt.conf , the last line is :
exec /bin/openvt -e -c 1 -f -- /bin/auto-root-login

I'm fairly sure that if you remove that script root will not longer automatically log on on tty1.

[Ekkehard]

Thanks @aquarat,

I was aware of that.  I had already commented out that one line in /etc/init/openvt.conf, but since it didn't change anything, I re-enabled it.

Next thing on the list is to take the x-flag away from /bin/auto-root-login.  If that makes the problem go away, I should be able to find who calls the darn thing - since it ain't /etc/init/openvt.conf.

I'll let you know how it goes.

[Ekkehard]

Weird - openvt reports "permission denied" when I do that.  Don't know why commenting out that line didn't fix it then.  Now, of course, the main console doesn't log in at all anymore but hangs - but I am still logged in via ssh (actually from two different machines - did I mention that I'm paranoid ?) - so I gave auto-root-login its x-flag back.  Next thing to try is change auto-root-login to simply /bin/login in openvt.conf - maybe that'll solve it.

[Ekkehard]

Success!!

Changing /bin/auto-root-login into /bin/login in the file /etc/init/openvt.conf fixed the issue.  Thank you so much for bringing it up @aquarat - I had already put it on the pile of "things that didn't work" - too early, as it turns out.  Now I can leave getty enabled on tty1 to be able to log in and use X for maintenance on calibre.

@jwischka, of course I will still check out your native Raring beta!!