From brcisna at eazylivin.net Sun Dec 21 13:34:40 2014 From: brcisna at eazylivin.net (Barry R Cisna) Date: Sun, 21 Dec 2014 07:34:40 -0600 Subject: [K12OSN] ldm ssh login failing Message-ID: <1419168880.22632.66.camel@server1.eazylivin.net> Hello All, Fresh install of CentOS 6.6 with the latest ltsp build. Problem: When logging in a client machine the user gets a hang of about 30 seconds,after entering password verifying password disappears,of a solid blue screen then drops back to long in screen. Never see the "restarting server" routine on this one. This is the same for root as well, for completeness. Troubleshooting stuff: After wrangling with this for 3 days off and on,I allowed only a shell login and the machine will come up to a root shell fine. I have re-installed the client build from scratch a second time and come with same situation. I have done the ltsp-update-sshkeys & ltsp-update-kernels umpteen times as well. Logs: What is very odd at the user(testuser) login ., the secure logs it shows the username is accepted by pam_unix , then directly after that there are many line of "failed password for root from serveripaddress". I never remember seeing the root password in logs before,or maybe because logins have always worked in all previous builds for me? ---------------------------------------------------------------------------- Dec 19 13:39:57 wc19 sshd[5072]: Accepted password for testuser from 172.28.12.5 port 45076 ssh2 Dec 19 13:39:57 wc19 sshd[5072]: pam_unix(sshd:session): session opened for user testuser by (uid=0) Dec 19 13:39:58 wc19 sshd[5097]: Failed password for root from 172.28.12.5 port 45077 ssh2 Dec 19 13:39:58 wc19 sshd[5097]: Failed password for root from 172.28.12.5 port 45077 ssh2 Dec 19 13:39:58 wc19 sshd[5099]: Connection closed by 172.28.12.5 Dec 19 13:39:58 wc19 sshd[5100]: Failed password for root from 172.28.12.5 port 45078 ssh2 Dec 19 13:39:58 wc19 sshd[5100]: Failed password for root from 172.28.12.5 port 45078 ssh2 Dec 19 13:39:58 wc19 sshd[5102]: Connection closed by 172.28.12.5 Dec 19 13:39:59 wc19 sshd[5103]: Failed password for root from 172.28.12.5 port 45079 ssh2 Dec 19 13:39:59 wc19 sshd[5103]: Failed password for root from 172.28.12.5 port 45079 ssh2 Dec 19 13:39:59 wc19 sshd[5105]: Connection closed by 172.28.12.5 Dec 19 13:39:59 wc19 sshd[5106]: Failed password for root from 172.28.12.5 port 45080 ssh2 Dec 19 13:39:59 wc19 sshd[5106]: Failed password for root from 172.28.12.5 port 45080 ssh2 Dec 19 13:39:59 wc19 sshd[5109]: Connection closed by 172.28.12.5 Dec 19 13:39:59 wc19 sshd[5110]: Failed password for root from 172.28.12.5 port 45081 ssh2 Dec 19 13:39:59 wc19 sshd[5110]: Failed password for root from 172.28.12.5 port 45081 ssh2 Dec 19 13:39:59 wc19 sshd[5112]: Connection closed by 172.28.12.5 Dec 19 13:40:00 wc19 sshd[5113]: Failed password for root from 172.28.12.5 port 45082 ssh2 Dec 19 13:40:00 wc19 sshd[5113]: Failed password for root from 172.28.12.5 port 45082 ssh2 Dec 19 13:40:00 wc19 sshd[5115]: Connection closed by 172.28.12.5 Dec 19 13:40:00 wc19 sshd[5116]: Failed password for root from 172.28.12.5 port 45083 ssh2 Dec 19 13:40:00 wc19 sshd[5116]: Failed password for root from 172.28.12.5 port 45083 ssh2 Dec 19 13:40:00 wc19 sshd[5118]: Connection closed by 172.28.12.5 Dec 19 13:40:00 wc19 sshd[5119]: Failed password for root from 172.28.12.5 port 45084 ssh2 Dec 19 13:40:00 wc19 sshd[5119]: Failed password for root from 172.28.12.5 port 45084 ssh2 Dec 19 13:40:00 wc19 sshd[5121]: Connection closed by 172.28.12.5 Dec 19 13:40:01 wc19 sshd[5122]: Failed password for root from 172.28.12.5 port 45085 ssh2 Dec 19 13:40:01 wc19 sshd[5122]: Failed password for root from 172.28.12.5 port 45085 ssh2 Dec 19 13:40:01 wc19 sshd[5124]: Connection closed by 172.28.12.5 Dec 19 13:40:02 wc19 sshd[5075]: Received disconnect from 172.28.12.5: 11: disconnected by user Dec 19 13:40:02 wc19 sshd[5072]: pam_unix(sshd:session): session closed for user testuser Dec 19 13:45:44 wc19 sshd[5333]: Accepted password for testuser from 172.28.12.5 port 45087 ssh2 ----------------------------------------------------------------------- Thank You, Barry From r.schuurmans at gmail.com Sun Dec 21 19:40:32 2014 From: r.schuurmans at gmail.com (Remke Schuurmans) Date: Sun, 21 Dec 2014 20:40:32 +0100 Subject: [K12OSN] K12OSN Digest, Vol 123, Issue 1 In-Reply-To: References: Message-ID: help 2014-12-21 18:00 GMT+01:00 : > Send K12OSN mailing list submissions to > k12osn at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/k12osn > or, via email, send a message with subject or body 'help' to > k12osn-request at redhat.com > > You can reach the person managing the list at > k12osn-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of K12OSN digest..." > > > Today's Topics: > > 1. ldm ssh login failing (Barry R Cisna) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 21 Dec 2014 07:34:40 -0600 > From: Barry R Cisna > To: K12LTSP > Subject: [K12OSN] ldm ssh login failing > Message-ID: <1419168880.22632.66.camel at server1.eazylivin.net> > Content-Type: text/plain; charset="UTF-8" > > Hello All, > > Fresh install of CentOS 6.6 with the latest ltsp build. > > Problem: > When logging in a client machine the user gets a hang of about 30 > seconds,after entering password verifying password disappears,of a > solid blue screen then drops back to long in screen. > Never see the "restarting server" routine on this one. > This is the same for root as well, for completeness. > > Troubleshooting stuff: > After wrangling with this for 3 days off and on,I allowed only a shell > login and the machine will come up to a root shell fine. > > I have re-installed the client build from scratch a second time and come > with same situation. > > I have done the ltsp-update-sshkeys & ltsp-update-kernels umpteen times > as well. > > Logs: > What is very odd at the user(testuser) login ., the secure logs it > shows the username is accepted by pam_unix , then directly after that > there are many line of "failed password for root from > serveripaddress". > I never remember seeing the root password in logs before,or maybe > because logins have always worked in all previous builds for me? > > > ---------------------------------------------------------------------------- > > Dec 19 13:39:57 wc19 sshd[5072]: Accepted password for testuser from > 172.28.12.5 port 45076 ssh2 > Dec 19 13:39:57 wc19 sshd[5072]: pam_unix(sshd:session): session opened > for user testuser by (uid=0) > Dec 19 13:39:58 wc19 sshd[5097]: Failed password for root from > 172.28.12.5 port 45077 ssh2 > Dec 19 13:39:58 wc19 sshd[5097]: Failed password for root from > 172.28.12.5 port 45077 ssh2 > Dec 19 13:39:58 wc19 sshd[5099]: Connection closed by 172.28.12.5 > Dec 19 13:39:58 wc19 sshd[5100]: Failed password for root from > 172.28.12.5 port 45078 ssh2 > Dec 19 13:39:58 wc19 sshd[5100]: Failed password for root from > 172.28.12.5 port 45078 ssh2 > Dec 19 13:39:58 wc19 sshd[5102]: Connection closed by 172.28.12.5 > Dec 19 13:39:59 wc19 sshd[5103]: Failed password for root from > 172.28.12.5 port 45079 ssh2 > Dec 19 13:39:59 wc19 sshd[5103]: Failed password for root from > 172.28.12.5 port 45079 ssh2 > Dec 19 13:39:59 wc19 sshd[5105]: Connection closed by 172.28.12.5 > Dec 19 13:39:59 wc19 sshd[5106]: Failed password for root from > 172.28.12.5 port 45080 ssh2 > Dec 19 13:39:59 wc19 sshd[5106]: Failed password for root from > 172.28.12.5 port 45080 ssh2 > Dec 19 13:39:59 wc19 sshd[5109]: Connection closed by 172.28.12.5 > Dec 19 13:39:59 wc19 sshd[5110]: Failed password for root from > 172.28.12.5 port 45081 ssh2 > Dec 19 13:39:59 wc19 sshd[5110]: Failed password for root from > 172.28.12.5 port 45081 ssh2 > Dec 19 13:39:59 wc19 sshd[5112]: Connection closed by 172.28.12.5 > Dec 19 13:40:00 wc19 sshd[5113]: Failed password for root from > 172.28.12.5 port 45082 ssh2 > Dec 19 13:40:00 wc19 sshd[5113]: Failed password for root from > 172.28.12.5 port 45082 ssh2 > Dec 19 13:40:00 wc19 sshd[5115]: Connection closed by 172.28.12.5 > Dec 19 13:40:00 wc19 sshd[5116]: Failed password for root from > 172.28.12.5 port 45083 ssh2 > Dec 19 13:40:00 wc19 sshd[5116]: Failed password for root from > 172.28.12.5 port 45083 ssh2 > Dec 19 13:40:00 wc19 sshd[5118]: Connection closed by 172.28.12.5 > Dec 19 13:40:00 wc19 sshd[5119]: Failed password for root from > 172.28.12.5 port 45084 ssh2 > Dec 19 13:40:00 wc19 sshd[5119]: Failed password for root from > 172.28.12.5 port 45084 ssh2 > Dec 19 13:40:00 wc19 sshd[5121]: Connection closed by 172.28.12.5 > Dec 19 13:40:01 wc19 sshd[5122]: Failed password for root from > 172.28.12.5 port 45085 ssh2 > Dec 19 13:40:01 wc19 sshd[5122]: Failed password for root from > 172.28.12.5 port 45085 ssh2 > Dec 19 13:40:01 wc19 sshd[5124]: Connection closed by 172.28.12.5 > Dec 19 13:40:02 wc19 sshd[5075]: Received disconnect from 172.28.12.5: > 11: disconnected by user > Dec 19 13:40:02 wc19 sshd[5072]: pam_unix(sshd:session): session closed > for user testuser > Dec 19 13:45:44 wc19 sshd[5333]: Accepted password for testuser from > 172.28.12.5 port 45087 ssh2 > > ----------------------------------------------------------------------- > > Thank You, > Barry > > > > > ------------------------------ > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > > End of K12OSN Digest, Vol 123, Issue 1 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brcisna at eazylivin.net Mon Dec 22 20:44:43 2014 From: brcisna at eazylivin.net (Barry R Cisna) Date: Mon, 22 Dec 2014 14:44:43 -0600 Subject: [K12OSN] login user is root Message-ID: <1419281083.22632.83.camel@server1.eazylivin.net> Hello All, I posted this over at ltsp forums. It seems the interest in ltsp has really diminished sadly,,and also makes troubleshooting a problem like i have listed that much more difficult,without anyone else being able to give much feedback on recent installs of ltsp. ------------------------------------------------ > CentOS 6.6 & ltsp latest version server & client build. > > After modding the sshd_config file on server to allow root to login with > authorized_keys files a standrad user can get a login now,,but after > logging in the standard user is root. > > It can be easily seen in log below the user (testuser) is authenticated > fine then next line root is logged in alongside stander user. > > Never had this happen in many builds of ltsp/k12linux over the years. > I will post the login of a client from the secure logs on server. > > ----------------------------------------------------------------------------------------------------------------------- > > Dec 22 09:32:14 wc19 sshd[11199]: Accepted password for testuser from > 172.28.12.5 port 42979 ssh2 > Dec 22 09:32:14 wc19 sshd[11199]: pam_unix(sshd:session): session opened > for user testuser by (uid=0) > Dec 22 09:32:15 wc19 sshd[11225]: Accepted publickey for root from > 172.28.12.5 port 42980 ssh2 > Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:15 wc19 sshd[11225]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:15 wc19 sshd[11244]: Accepted publickey for root from > 172.28.12.5 port 42981 ssh2 > Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:15 wc19 sshd[11244]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:15 wc19 sshd[11263]: Accepted publickey for root from > 172.28.12.5 port 42982 ssh2 > Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:15 wc19 sshd[11263]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:16 wc19 sshd[11283]: Accepted publickey for root from > 172.28.12.5 port 42983 ssh2 > Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:16 wc19 sshd[11283]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:16 wc19 sshd[11302]: Accepted publickey for root from > 172.28.12.5 port 42984 ssh2 > Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:16 wc19 sshd[11302]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:16 wc19 sshd[11321]: Accepted publickey for root from > 172.28.12.5 port 42985 ssh2 > Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:16 wc19 sshd[11321]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:17 wc19 sshd[11340]: Accepted publickey for root from > 172.28.12.5 port 42986 ssh2 > Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:17 wc19 sshd[11340]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:17 wc19 sshd[11360]: Accepted publickey for root from > 172.28.12.5 port 42987 ssh2 > Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:17 wc19 sshd[11360]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:18 wc19 sshd[11379]: Accepted publickey for root from > 172.28.12.5 port 42988 ssh2 > Dec 22 09:32:18 wc19 sshd[11379]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:21 wc19 polkitd(authority=local): Registered Authentication > Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name > :1.1461 [/usr/libexec/polkit-gnome-authentication-agent-1], object path > /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) > Dec 22 09:32:49 wc19 sshd[11379]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:49 wc19 sshd[11379]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:50 wc19 sshd[11202]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:50 wc19 sshd[11199]: pam_unix(sshd:session): session closed > for user testuser > Dec 22 09:32:50 wc19 polkitd(authority=local): Unregistered Authentication > Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name > :1.1461, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale > en_US.UTF-8) (disconnected from bus) > > ---------------------------------------------------------------------------------------------------------------------- > > Anyone ever experienced this? > > Thanks, > Barry From johan.vermeulen7 at telenet.be Mon Dec 22 21:16:55 2014 From: johan.vermeulen7 at telenet.be (Johan Vermeulen) Date: Mon, 22 Dec 2014 22:16:55 +0100 Subject: [K12OSN] : login user is root Message-ID: Barry, it should not be nescessary to modify the sshd_config file. The ltsp- update-ssh-keys should do it. Have you tried disabling the firewall? And selinux? Greetings johan Barry R Cisna schreef: >Hello All, > >I posted this over at ltsp forums. > >It seems the interest in ltsp has really diminished sadly,,and also >makes troubleshooting a problem like i have listed that much more >difficult,without anyone else being able to give much feedback on recent >installs of ltsp. > >------------------------------------------------ > > >> CentOS 6.6 & ltsp latest version server & client build. >> >> After modding the sshd_config file on server to allow root to login with >> authorized_keys files a standrad user can get a login now,,but after >> logging in the standard user is root. >> >> It can be easily seen in log below the user (testuser) is authenticated >> fine then next line root is logged in alongside stander user. >> >> Never had this happen in many builds of ltsp/k12linux over the years. >> I will post the login of a client from the secure logs on server. >> >> ----------------------------------------------------------------------------------------------------------------------- >> >> Dec 22 09:32:14 wc19 sshd[11199]: Accepted password for testuser from >> 172.28.12.5 port 42979 ssh2 >> Dec 22 09:32:14 wc19 sshd[11199]: pam_unix(sshd:session): session opened >> for user testuser by (uid=0) >> Dec 22 09:32:15 wc19 sshd[11225]: Accepted publickey for root from >> 172.28.12.5 port 42980 ssh2 >> Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:15 wc19 sshd[11225]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:15 wc19 sshd[11244]: Accepted publickey for root from >> 172.28.12.5 port 42981 ssh2 >> Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:15 wc19 sshd[11244]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:15 wc19 sshd[11263]: Accepted publickey for root from >> 172.28.12.5 port 42982 ssh2 >> Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:15 wc19 sshd[11263]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:16 wc19 sshd[11283]: Accepted publickey for root from >> 172.28.12.5 port 42983 ssh2 >> Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:16 wc19 sshd[11283]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:16 wc19 sshd[11302]: Accepted publickey for root from >> 172.28.12.5 port 42984 ssh2 >> Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:16 wc19 sshd[11302]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:16 wc19 sshd[11321]: Accepted publickey for root from >> 172.28.12.5 port 42985 ssh2 >> Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:16 wc19 sshd[11321]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:17 wc19 sshd[11340]: Accepted publickey for root from >> 172.28.12.5 port 42986 ssh2 >> Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:17 wc19 sshd[11340]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:17 wc19 sshd[11360]: Accepted publickey for root from >> 172.28.12.5 port 42987 ssh2 >> Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:17 wc19 sshd[11360]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:18 wc19 sshd[11379]: Accepted publickey for root from >> 172.28.12.5 port 42988 ssh2 >> Dec 22 09:32:18 wc19 sshd[11379]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Dec 22 09:32:21 wc19 polkitd(authority=local): Registered Authentication >> Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name >> :1.1461 [/usr/libexec/polkit-gnome-authentication-agent-1], object path >> /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) >> Dec 22 09:32:49 wc19 sshd[11379]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:49 wc19 sshd[11379]: pam_unix(sshd:session): session closed >> for user root >> Dec 22 09:32:50 wc19 sshd[11202]: Received disconnect from 172.28.12.5: 11: >> disconnected by user >> Dec 22 09:32:50 wc19 sshd[11199]: pam_unix(sshd:session): session closed >> for user testuser >> Dec 22 09:32:50 wc19 polkitd(authority=local): Unregistered Authentication >> Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name >> :1.1461, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale >> en_US.UTF-8) (disconnected from bus) >> >> ---------------------------------------------------------------------------------------------------------------------- >> >> Anyone ever experienced this? >> >> Thanks, >> Barry > >_______________________________________________ >K12OSN mailing list >K12OSN at redhat.com >https://www.redhat.com/mailman/listinfo/k12osn >For more info see From brcisna at eazylivin.net Mon Dec 22 22:39:39 2014 From: brcisna at eazylivin.net (Barry R Cisna) Date: Mon, 22 Dec 2014 16:39:39 -0600 Subject: [K12OSN] : login user is root Message-ID: <1419287979.22632.100.camel@server1.eazylivin.net> Hi Johan, Yes selinux and iptables are both disabled at boot. I have used ltsp/k12linux for anbout 11 years now so fairly familiar with the configs,but each iteration of ltsp-server throws new curve balls it goes without saying. The reason for modding the sshd_config file was due to the fact that root was failing the login for a standard user. Without adding the public keys for root to both server and client root,the standard user was thrown back out to the login screen again. Yes, i am familiar with doing the ltsp-update-sshkeys, along with ltsp-update-kernels. Downside is now the login works,but a standard user,,,is root once logged in. If you look at the log below,,you will see at top,,,a standard user,,then directly below,root gets the go ahead from ssh? Scouring through the ldm files, there is yet another ldm package that is installed, with ltsp-server package ,,even since I done an install about 6 months ago,that worked fine. I am sure it is of course something is haywire in the ldm init scripts but don't have a clue were to look,,to troubleshoot. Also,i noticed randomly after adding the LDM_DEBUG_TERMINAL in the lts.cong file,,i see randon "ldm: segfault at 8 ip. xxx" , in the popup terminal on the client, I found reference to this error as far back as two year ago,,but never found what a real solution was or what caused this. Thanks, Barry From burke at thealmquists.net Tue Dec 23 00:46:55 2014 From: burke at thealmquists.net (=?utf-8?B?YnVya2VAdGhlYWxtcXVpc3RzLm5ldA==?=) Date: Mon, 22 Dec 2014 18:46:55 -0600 Subject: [K12OSN] =?utf-8?q?login_user_is_root?= Message-ID: <201412230046.sBN0kpNP019157@www.thealmquists.net> I've noticed that the list has really slowed down as well. I guess most of the LTSP action has moved to Ubuntu, where most of the users and developers have gone. ----- Reply message ----- From: "Barry R Cisna" To: "K12LTSP" Subject: [K12OSN] login user is root Date: Mon, Dec 22, 2014 2:44 PM Hello All, I posted this over at ltsp forums. It seems the interest in ltsp has really diminished sadly,,and also makes troubleshooting a problem like i have listed that much more difficult,without anyone else being able to give much feedback on recent installs of ltsp. ------------------------------------------------ > CentOS 6.6 & ltsp latest version server & client build. > > After modding the sshd_config file on server to allow root to login with > authorized_keys files a standrad user can get a login now,,but after > logging in the standard user is root. > > It can be easily seen in log below the user (testuser) is authenticated > fine then next line root is logged in alongside stander user. > > Never had this happen in many builds of ltsp/k12linux over the years. > I will post the login of a client from the secure logs on server. > > ----------------------------------------------------------------------------------------------------------------------- > > Dec 22 09:32:14 wc19 sshd[11199]: Accepted password for testuser from > 172.28.12.5 port 42979 ssh2 > Dec 22 09:32:14 wc19 sshd[11199]: pam_unix(sshd:session): session opened > for user testuser by (uid=0) > Dec 22 09:32:15 wc19 sshd[11225]: Accepted publickey for root from > 172.28.12.5 port 42980 ssh2 > Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:15 wc19 sshd[11225]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:15 wc19 sshd[11244]: Accepted publickey for root from > 172.28.12.5 port 42981 ssh2 > Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:15 wc19 sshd[11244]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:15 wc19 sshd[11263]: Accepted publickey for root from > 172.28.12.5 port 42982 ssh2 > Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:15 wc19 sshd[11263]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:16 wc19 sshd[11283]: Accepted publickey for root from > 172.28.12.5 port 42983 ssh2 > Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:16 wc19 sshd[11283]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:16 wc19 sshd[11302]: Accepted publickey for root from > 172.28.12.5 port 42984 ssh2 > Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:16 wc19 sshd[11302]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:16 wc19 sshd[11321]: Accepted publickey for root from > 172.28.12.5 port 42985 ssh2 > Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:16 wc19 sshd[11321]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:17 wc19 sshd[11340]: Accepted publickey for root from > 172.28.12.5 port 42986 ssh2 > Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:17 wc19 sshd[11340]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:17 wc19 sshd[11360]: Accepted publickey for root from > 172.28.12.5 port 42987 ssh2 > Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:17 wc19 sshd[11360]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:18 wc19 sshd[11379]: Accepted publickey for root from > 172.28.12.5 port 42988 ssh2 > Dec 22 09:32:18 wc19 sshd[11379]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Dec 22 09:32:21 wc19 polkitd(authority=local): Registered Authentication > Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name > :1.1461 [/usr/libexec/polkit-gnome-authentication-agent-1], object path > /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) > Dec 22 09:32:49 wc19 sshd[11379]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:49 wc19 sshd[11379]: pam_unix(sshd:session): session closed > for user root > Dec 22 09:32:50 wc19 sshd[11202]: Received disconnect from 172.28.12.5: 11: > disconnected by user > Dec 22 09:32:50 wc19 sshd[11199]: pam_unix(sshd:session): session closed > for user testuser > Dec 22 09:32:50 wc19 polkitd(authority=local): Unregistered Authentication > Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name > :1.1461, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale > en_US.UTF-8) (disconnected from bus) > > ---------------------------------------------------------------------------------------------------------------------- > > Anyone ever experienced this? > > Thanks, > Barry _______________________________________________ K12OSN mailing list K12OSN at redhat.com https://www.redhat.com/mailman/listinfo/k12osn For more info see -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.kinney at gmail.com Tue Dec 23 04:14:12 2014 From: jim.kinney at gmail.com (Jim Kinney) Date: Mon, 22 Dec 2014 23:14:12 -0500 Subject: [K12OSN] login user is root In-Reply-To: <201412230046.sBN0kpNP019157@www.thealmquists.net> References: <201412230046.sBN0kpNP019157@www.thealmquists.net> Message-ID: Lot's of stuff has changed. RedHat is pushing virtualization. LTSP in Ubuntu is still an afterthought but at least it exists. I'm still working to transition ltsp to a pxe boot plus spice client environment. That is the next phase in my thinking of centos server for school use with freeipa authentication and ovirt virtualization management. On Dec 22, 2014 5:57 PM, "burke at thealmquists.net" wrote: > I've noticed that the list has really slowed down as well. I guess most > of the LTSP action has moved to Ubuntu, where most of the users and > developers have gone. > ----- Reply message ----- > From: "Barry R Cisna" > To: "K12LTSP" > Subject: [K12OSN] login user is root > Date: Mon, Dec 22, 2014 2:44 PM > > Hello All, > > I posted this over at ltsp forums. > > It seems the interest in ltsp has really diminished sadly,,and also > makes troubleshooting a problem like i have listed that much more > difficult,without anyone else being able to give much feedback on recent > installs of ltsp. > > ------------------------------------------------ > > > > CentOS 6.6 & ltsp latest version server & client build. > > > > After modding the sshd_config file on server to allow root to login with > > authorized_keys files a standrad user can get a login now,,but after > > logging in the standard user is root. > > > > It can be easily seen in log below the user (testuser) is authenticated > > fine then next line root is logged in alongside stander user. > > > > Never had this happen in many builds of ltsp/k12linux over the years. > > I will post the login of a client from the secure logs on server. > > > > ----------------------------------------------------------------------------------------------------------------------- > > > > Dec 22 09:32:14 wc19 sshd[11199]: Accepted password for testuser from > > 172.28.12.5 port 42979 ssh2 > > Dec 22 09:32:14 wc19 sshd[11199]: pam_unix(sshd:session): session opened > > for user testuser by (uid=0) > > Dec 22 09:32:15 wc19 sshd[11225]: Accepted publickey for root from > > 172.28.12.5 port 42980 ssh2 > > Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:15 wc19 sshd[11225]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:15 wc19 sshd[11225]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:15 wc19 sshd[11244]: Accepted publickey for root from > > 172.28.12.5 port 42981 ssh2 > > Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:15 wc19 sshd[11244]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:15 wc19 sshd[11244]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:15 wc19 sshd[11263]: Accepted publickey for root from > > 172.28.12.5 port 42982 ssh2 > > Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:15 wc19 sshd[11263]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:15 wc19 sshd[11263]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:16 wc19 sshd[11283]: Accepted publickey for root from > > 172.28.12.5 port 42983 ssh2 > > Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:16 wc19 sshd[11283]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:16 wc19 sshd[11283]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:16 wc19 sshd[11302]: Accepted publickey for root from > > 172.28.12.5 port 42984 ssh2 > > Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:16 wc19 sshd[11302]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:16 wc19 sshd[11302]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:16 wc19 sshd[11321]: Accepted publickey for root from > > 172.28.12.5 port 42985 ssh2 > > Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:16 wc19 sshd[11321]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:16 wc19 sshd[11321]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:17 wc19 sshd[11340]: Accepted publickey for root from > > 172.28.12.5 port 42986 ssh2 > > Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:17 wc19 sshd[11340]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:17 wc19 sshd[11340]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:17 wc19 sshd[11360]: Accepted publickey for root from > > 172.28.12.5 port 42987 ssh2 > > Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:17 wc19 sshd[11360]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:17 wc19 sshd[11360]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:18 wc19 sshd[11379]: Accepted publickey for root from > > 172.28.12.5 port 42988 ssh2 > > Dec 22 09:32:18 wc19 sshd[11379]: pam_unix(sshd:session): session opened > > for user root by (uid=0) > > Dec 22 09:32:21 wc19 polkitd(authority=local): Registered Authentication > > Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name > > :1.1461 [/usr/libexec/polkit-gnome-authentication-agent-1], object path > > /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) > > Dec 22 09:32:49 wc19 sshd[11379]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:49 wc19 sshd[11379]: pam_unix(sshd:session): session closed > > for user root > > Dec 22 09:32:50 wc19 sshd[11202]: Received disconnect from 172.28.12.5: 11: > > disconnected by user > > Dec 22 09:32:50 wc19 sshd[11199]: pam_unix(sshd:session): session closed > > for user testuser > > Dec 22 09:32:50 wc19 polkitd(authority=local): Unregistered Authentication > > Agent for session /org/freedesktop/ConsoleKit/Session9 (system bus name > > :1.1461, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale > > en_US.UTF-8) (disconnected from bus) > > > > ---------------------------------------------------------------------------------------------------------------------- > > > > Anyone ever experienced this? > > > > Thanks, > > Barry > > _______________________________________________ > K12OSN mailing listK12OSN at redhat.comhttps://www.redhat.com/mailman/listinfo/k12osn > For more info see > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vermeulen7 at telenet.be Tue Dec 23 11:13:50 2014 From: johan.vermeulen7 at telenet.be (Johan Vermeulen) Date: Tue, 23 Dec 2014 12:13:50 +0100 Subject: [K12OSN] : login user is root Message-ID: Barry, the most recent "standard" install I did was on Centos6.5 I don't remember if I used epel or k12linux repo. I had no issues. Usualy I don't don't do normal install but I set up dhcp, nfs, etc manualy and copy over files from a pre-fedorahosted k12linux. For me moving to ubuntu is a noway. Greetings johan Barry R Cisna schreef: >Hi Johan, > >Yes selinux and iptables are both disabled at boot. >I have used ltsp/k12linux for anbout 11 years now so fairly familiar >with the configs,but each iteration of ltsp-server throws new curve >balls it goes without saying. > > >The reason for modding the sshd_config file was due to the fact that >root was failing the login for a standard user. >Without adding the public >keys for root to both server and client root,the standard user was >thrown back out to the login screen again. >Yes, i am familiar with doing the ltsp-update-sshkeys, along with >ltsp-update-kernels. > >Downside is now the login works,but a standard user,,,is root once >logged in. > >If you look at the log below,,you will see at top,,,a standard >user,,then directly below,root gets the go ahead from ssh? >Scouring through the ldm files, there is yet another ldm package that is >installed, with ltsp-server package ,,even since I done an install about >6 months ago,that worked fine. > >I am sure it is of course something is haywire in the ldm init scripts >but don't have a clue were to look,,to troubleshoot. > >Also,i noticed randomly after adding the LDM_DEBUG_TERMINAL in the >lts.cong file,,i see randon "ldm: segfault at 8 ip. xxx" , in the popup >terminal on the client, >I found reference to this error as far back as two year ago,,but never >found what a real solution was or what caused this. > > >Thanks, > >Barry > >_______________________________________________ >K12OSN mailing list >K12OSN at redhat.com >https://www.redhat.com/mailman/listinfo/k12osn >For more info see From radek at bursztynowski.waw.pl Tue Dec 23 12:38:19 2014 From: radek at bursztynowski.waw.pl (Radek Bursztynowski) Date: Tue, 23 Dec 2014 13:38:19 +0100 Subject: [K12OSN] : login user is root In-Reply-To: References: Message-ID: <1419338299.13982.1.camel@alpaga.bursztynowski.waw.pl> Hello, Let me add my feelings to this discussion. I use K12Linux on CentOS 6.x for many years and for me moving to another solution is a noway too. Unfortunately I meet a lot of troubles, but most of them I solve manually. Last my installation CentOS 6.6 and K12Linux is dated 3th of November 2014. I solved most problems and this installation works stable, but I have problem with thin client image. Only one thin client image is installable from my point of view: epel-6-i386 (i386). ltsp-build-client -?list shows: epel-5-i386 epel-5-ppc epel-5-x86_64 epel-6-i386 epel-6-ppc64 epel-6-x86_64 epel-7-x86_64 fedora-19-armhfp fedora-19-i386 fedora-19-ppc64 fedora-19-ppc fedora-19-s390 fedora-19-s390x fedora-19-x86_64 fedora-20-armhfp fedora-20-i386 fedora-20-ppc64 fedora-20-ppc fedora-20-s390 fedora-20-s390x fedora-20-x86_64 fedora-21-armhfp fedora-21-i386 fedora-21-x86_64 fedora-5-i386-epel fedora-5-ppc-epel fedora-5-x86_64-epel fedora-devel-i386 fedora-devel-ppc64 fedora-devel-ppc fedora-devel-x86_64 fedora-rawhide-aarch64 fedora-rawhide-armhfp fedora-rawhide-i386 fedora-rawhide-ppc64 fedora-rawhide-ppc fedora-rawhide-s390 fedora-rawhide-s390x fedora-rawhide-sparc fedora-rawhide-x86_64 but epel-6-i386 I can install only. I don't know why. LTSP terminal boots with epel-6-i386 (CentOS 6.6) but I can't login. In addition epel-6-i386 (the last one and older) image couldn't shutdown. Ending process suspends on switching off eth0 interface. So, I still use Scientific Linux 6.1 image and fedora-11-i386 for older (i586) images. epel-6-i386 and fedora-11-i386 (epel-6-i386 too) don't support properly newest graphic cards inside new nettops or thin clients terminals with full resolution. And this is the reason that I am looking for newer thin client images. I tried debian-7-i386 thin client image - no better result. Next step I plan with OpenSUSE image and at the end with Ubuntu image. But I am concerned about K12Linux thin client images because this status of thin client images doesn't change whole year and I wary that older hardware nettop/thin clients solution will end. The future is misty. Best regards, Radek ------ > Barry, > > the most recent "standard" install I did was on Centos6.5 > I don't remember if I used epel or k12linux repo. I had no issues. > Usualy I don't don't do normal install but I set up dhcp, nfs, etc manualy and copy over files from a pre-fedorahosted k12linux. > For me moving to ubuntu is a noway. > Greetings johan > > Barry R Cisna schreef: > > >Hi Johan, > > > >Yes selinux and iptables are both disabled at boot. > >I have used ltsp/k12linux for anbout 11 years now so fairly familiar > >with the configs,but each iteration of ltsp-server throws new curve > >balls it goes without saying. > > > > > >The reason for modding the sshd_config file was due to the fact that > >root was failing the login for a standard user. > >Without adding the public > >keys for root to both server and client root,the standard user was > >thrown back out to the login screen again. > >Yes, i am familiar with doing the ltsp-update-sshkeys, along with > >ltsp-update-kernels. > > > >Downside is now the login works,but a standard user,,,is root once > >logged in. > > > >If you look at the log below,,you will see at top,,,a standard > >user,,then directly below,root gets the go ahead from ssh? > >Scouring through the ldm files, there is yet another ldm package that is > >installed, with ltsp-server package ,,even since I done an install about > >6 months ago,that worked fine. > > > >I am sure it is of course something is haywire in the ldm init scripts > >but don't have a clue were to look,,to troubleshoot. > > > >Also,i noticed randomly after adding the LDM_DEBUG_TERMINAL in the > >lts.cong file,,i see randon "ldm: segfault at 8 ip. xxx" , in the popup > >terminal on the client, > >I found reference to this error as far back as two year ago,,but never > >found what a real solution was or what caused this. > > > > > >Thanks, > > > >Barry > > > >_______________________________________________ > >K12OSN mailing list > >K12OSN at redhat.com > >https://www.redhat.com/mailman/listinfo/k12osn > >For more info see > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see From brcisna at eazylivin.net Tue Dec 23 13:55:34 2014 From: brcisna at eazylivin.net (Barry R Cisna) Date: Tue, 23 Dec 2014 07:55:34 -0600 Subject: [K12OSN] standard user login becomes root Message-ID: <1419342934.22838.5.camel@server1.eazylivin.net> Hello All, A second post in regards to my new install of ltsp with CentOS 6.6 I think last post I wasn't very clear on what the actual problem is happening. When any standard user logs in the user strangely becomes root. I force uninstalled the 2 ldm packages on both server and client and installed the ldminfod.rpm of a working server i done only about 6 months ago. This did not cure the problem Has anyone ever tried doing an install of gdm,on any recent installs of ltsp? It seems something is amiss in the ldm,configs and i am surely unable to see what the problem I've spent a lot of time trying to get this resolved and still no advancements. Thank You, Barry From johan.vermeulen7 at telenet.be Tue Dec 23 14:43:59 2014 From: johan.vermeulen7 at telenet.be (Johan Vermeulen) Date: Tue, 23 Dec 2014 15:43:59 +0100 Subject: [K12OSN] : login user is root Message-ID: This is very usefull. I asumed the problem with shutting down was because of my thinclient hardware. I also use the scientific-image. I also have one site running on Thinstation. Greetings, Johan Radek Bursztynowski schreef: >Hello, > >Let me add my feelings to this discussion. I use K12Linux on CentOS 6.x >for many years and for me moving to another solution is a noway too. >Unfortunately I meet a lot of troubles, but most of them I solve >manually. Last my installation CentOS 6.6 and K12Linux is dated 3th of >November 2014. I solved most problems and this installation works >stable, but I have problem with thin client image. > >Only one thin client image is installable from my point of view: >epel-6-i386 (i386). ltsp-build-client -?list shows: > epel-5-i386 > epel-5-ppc > epel-5-x86_64 > epel-6-i386 > epel-6-ppc64 > epel-6-x86_64 > epel-7-x86_64 > fedora-19-armhfp > fedora-19-i386 > fedora-19-ppc64 > fedora-19-ppc > fedora-19-s390 > fedora-19-s390x > fedora-19-x86_64 > fedora-20-armhfp > fedora-20-i386 > fedora-20-ppc64 > fedora-20-ppc > fedora-20-s390 > fedora-20-s390x > fedora-20-x86_64 > fedora-21-armhfp > fedora-21-i386 > fedora-21-x86_64 > fedora-5-i386-epel > fedora-5-ppc-epel > fedora-5-x86_64-epel > fedora-devel-i386 > fedora-devel-ppc64 > fedora-devel-ppc > fedora-devel-x86_64 > fedora-rawhide-aarch64 > fedora-rawhide-armhfp > fedora-rawhide-i386 > fedora-rawhide-ppc64 > fedora-rawhide-ppc > fedora-rawhide-s390 > fedora-rawhide-s390x > fedora-rawhide-sparc > fedora-rawhide-x86_64 > >but epel-6-i386 I can install only. I don't know why. LTSP terminal >boots with epel-6-i386 (CentOS 6.6) but I can't login. In addition >epel-6-i386 (the last one and older) image couldn't shutdown. Ending >process suspends on switching off eth0 interface. So, I still use >Scientific Linux 6.1 image and fedora-11-i386 for older (i586) images. >epel-6-i386 and fedora-11-i386 (epel-6-i386 too) don't support properly >newest graphic cards inside new nettops or thin clients terminals with >full resolution. And this is the reason that I am looking for newer thin >client images. I tried debian-7-i386 thin client image - no better >result. >Next step I plan with OpenSUSE image and at the end with Ubuntu image. >But I am concerned about K12Linux thin client images because this status >of thin client images doesn't change whole year and I wary that older >hardware nettop/thin clients solution will end. > >The future is misty. > >Best regards, >Radek > >------ >> Barry, >> >> the most recent "standard" install I did was on Centos6.5 >> I don't remember if I used epel or k12linux repo. I had no issues. >> Usualy I don't don't do normal install but I set up dhcp, nfs, etc manualy and copy over files from a pre-fedorahosted k12linux. >> For me moving to ubuntu is a noway. >> Greetings johan >> >> Barry R Cisna schreef: >> >> >Hi Johan, >> > >> >Yes selinux and iptables are both disabled at boot. >> >I have used ltsp/k12linux for anbout 11 years now so fairly familiar >> >with the configs,but each iteration of ltsp-server throws new curve >> >balls it goes without saying. >> > >> > >> >The reason for modding the sshd_config file was due to the fact that >> >root was failing the login for a standard user. >> >Without adding the public >> >keys for root to both server and client root,the standard user was >> >thrown back out to the login screen again. >> >Yes, i am familiar with doing the ltsp-update-sshkeys, along with >> >ltsp-update-kernels. >> > >> >Downside is now the login works,but a standard user,,,is root once >> >logged in. >> > >> >If you look at the log below,,you will see at top,,,a standard >> >user,,then directly below,root gets the go ahead from ssh? >> >Scouring through the ldm files, there is yet another ldm package that is >> >installed, with ltsp-server package ,,even since I done an install about >> >6 months ago,that worked fine. >> > >> >I am sure it is of course something is haywire in the ldm init scripts >> >but don't have a clue were to look,,to troubleshoot. >> > >> >Also,i From radek at bursztynowski.waw.pl Tue Dec 23 15:27:25 2014 From: radek at bursztynowski.waw.pl (Radek Bursztynowski) Date: Tue, 23 Dec 2014 16:27:25 +0100 Subject: [K12OSN] : login user is root In-Reply-To: References: Message-ID: <1419348445.13982.4.camel@alpaga.bursztynowski.waw.pl> Johan, Regarding shutting down of NIC - I checked it on all my terminals and on virtual (KVM) machine too. This problem concerns thin client image, not hardware. Best regards, Radek > This is very usefull. > I asumed the problem with shutting down was because of my thinclient hardware. > I also use the scientific-image. > I also have one site running on Thinstation. > > Greetings, Johan > > Radek Bursztynowski schreef: > > >Hello, > > > >Let me add my feelings to this discussion. I use K12Linux on CentOS 6.x > >for many years and for me moving to another solution is a noway too. > >Unfortunately I meet a lot of troubles, but most of them I solve > >manually. Last my installation CentOS 6.6 and K12Linux is dated 3th of > >November 2014. I solved most problems and this installation works > >stable, but I have problem with thin client image. > > > >Only one thin client image is installable from my point of view: > >epel-6-i386 (i386). ltsp-build-client -?list shows: > > epel-5-i386 > > epel-5-ppc > > epel-5-x86_64 > > epel-6-i386 > > epel-6-ppc64 > > epel-6-x86_64 > > epel-7-x86_64 > > fedora-19-armhfp > > fedora-19-i386 > > fedora-19-ppc64 > > fedora-19-ppc > > fedora-19-s390 > > fedora-19-s390x > > fedora-19-x86_64 > > fedora-20-armhfp > > fedora-20-i386 > > fedora-20-ppc64 > > fedora-20-ppc > > fedora-20-s390 > > fedora-20-s390x > > fedora-20-x86_64 > > fedora-21-armhfp > > fedora-21-i386 > > fedora-21-x86_64 > > fedora-5-i386-epel > > fedora-5-ppc-epel > > fedora-5-x86_64-epel > > fedora-devel-i386 > > fedora-devel-ppc64 > > fedora-devel-ppc > > fedora-devel-x86_64 > > fedora-rawhide-aarch64 > > fedora-rawhide-armhfp > > fedora-rawhide-i386 > > fedora-rawhide-ppc64 > > fedora-rawhide-ppc > > fedora-rawhide-s390 > > fedora-rawhide-s390x > > fedora-rawhide-sparc > > fedora-rawhide-x86_64 > > > >but epel-6-i386 I can install only. I don't know why. LTSP terminal > >boots with epel-6-i386 (CentOS 6.6) but I can't login. In addition > >epel-6-i386 (the last one and older) image couldn't shutdown. Ending > >process suspends on switching off eth0 interface. So, I still use > >Scientific Linux 6.1 image and fedora-11-i386 for older (i586) images. > >epel-6-i386 and fedora-11-i386 (epel-6-i386 too) don't support properly > >newest graphic cards inside new nettops or thin clients terminals with > >full resolution. And this is the reason that I am looking for newer thin > >client images. I tried debian-7-i386 thin client image - no better > >result. > >Next step I plan with OpenSUSE image and at the end with Ubuntu image. > >But I am concerned about K12Linux thin client images because this status > >of thin client images doesn't change whole year and I wary that older > >hardware nettop/thin clients solution will end. > > > >The future is misty. > > > >Best regards, > >Radek > > > >------ > >> Barry, > >> > >> the most recent "standard" install I did was on Centos6.5 > >> I don't remember if I used epel or k12linux repo. I had no issues. > >> Usualy I don't don't do normal install but I set up dhcp, nfs, etc manualy and copy over files from a pre-fedorahosted k12linux. > >> For me moving to ubuntu is a noway. > >> Greetings johan > >> > >> Barry R Cisna schreef: > >> > >> >Hi Johan, > >> > > >> >Yes selinux and iptables are both disabled at boot. > >> >I have used ltsp/k12linux for anbout 11 years now so fairly familiar > >> >with the configs,but each iteration of ltsp-server throws new curve > >> >balls it goes without saying. > >> > > >> > > >> >The reason for modding the sshd_config file was due to the fact that > >> >root was failing the login for a standard user. > >> >Without adding the public > >> >keys for root to both server and client root,the standard user was > >> >thrown back out to the login screen again. > >> >Yes, i am familiar with doing the ltsp-update-sshkeys, along with > >> >ltsp-update-kernels. > >> > > >> >Downside is now the login works,but a standard user,,,is root once > >> >logged in. > >> > > >> >If you look at the log below,,you will see at top,,,a standard > >> >user,,then directly below,root gets the go ahead from ssh? > >> >Scouring through the ldm files, there is yet another ldm package that is > >> >installed, with ltsp-server package ,,even since I done an install about > >> >6 months ago,that worked fine. > >> > > >> >I am sure it is of course something is haywire in the ldm init scripts > >> >but don't have a clue were to look,,to troubleshoot. > >> > > >> >Also,i From brcisna at eazylivin.net Sun Dec 28 16:41:56 2014 From: brcisna at eazylivin.net (Barry R Cisna) Date: Sun, 28 Dec 2014 10:41:56 -0600 Subject: [K12OSN] Possible to install from old K12Linux repo's? Message-ID: <1419784916.22632.205.camel@server1.eazylivin.net> Hello All, Can anyone give any insight on,if it is possible to manually add an entry in yum.repos.d to pull from the old K12Linux repos that reside on ancl.hawaii? It appears the repos are still in order there but of course the actual ltsp.rpm is longer there. Been trying for the last week to get the latest spin of LTSP to work on CentOS 6.6 with no luck. What happens on latest server/client build of LTSP: 1) a user tries to log in In secure logs userxyz is accepted by pam_linux. Directly after this "failed password for root from (serveripaddess) by ssh2". 2) If i manually generate authorized_keys for root on server then transfer to root in ltsp chroot, the user gets logged in but is root at the client desktop. 3) If i setup lts.conf for only a shell login i see about 8 lines of, "ldm[### segfault at 8 ip" Then shell comes up to an expected bash prompt after these 8 lines. I am guessing this is not a good thing of course I have done memtest86 on this server for 2$ hours to make sure memory is not flakey. Haven't figured out if this is do ldm or ssh or a combination. I tried setting up the ltsp-lighdm hack but it was a battle also and is written for debian and bottom line wouldn't install to CentOS :( Out of ideas. I need to get the server back into production to supply some seats in a classroom. Thank You, Barry From jim.kinney at gmail.com Sun Dec 28 21:26:16 2014 From: jim.kinney at gmail.com (Jim Kinney) Date: Sun, 28 Dec 2014 16:26:16 -0500 Subject: [K12OSN] Possible to install from old K12Linux repo's? In-Reply-To: <1419784916.22632.205.camel@server1.eazylivin.net> References: <1419784916.22632.205.camel@server1.eazylivin.net> Message-ID: You should be able to modify an existing ltsp repo file to also pull from the other site. Just pattern match the base= line to wind up in the correct location. On Dec 28, 2014 11:45 AM, "Barry R Cisna" wrote: > Hello All, > > Can anyone give any insight on,if it is possible to manually add an > entry in yum.repos.d to pull from the old K12Linux repos that reside on > ancl.hawaii? > It appears the repos are still in order there but of course the actual > ltsp.rpm is longer there. > > Been trying for the last week to get the latest spin of LTSP to work on > CentOS 6.6 with no luck. > > What happens on latest server/client build of LTSP: > > 1) a user tries to log in > In secure logs userxyz is accepted by pam_linux. Directly after this > "failed password for root from (serveripaddess) by ssh2". > 2) If i manually generate authorized_keys for root on server then > transfer to root in ltsp chroot, the user gets logged in but is root at > the client desktop. > 3) If i setup lts.conf for only a shell login i see about 8 lines of, > "ldm[### segfault at 8 ip" > Then shell comes up to an expected bash prompt after these 8 lines. > I am guessing this is not a good thing of course > > I have done memtest86 on this server for 2$ hours to make sure memory is > not flakey. > > Haven't figured out if this is do ldm or ssh or a combination. > > I tried setting up the ltsp-lighdm hack but it was a battle also and is > written for debian and bottom line wouldn't install to CentOS :( > > Out of ideas. > > I need to get the server back into production to supply some seats in a > classroom. > > Thank You, > Barry > > > > > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k12ltsp at rwcinc.net Mon Dec 29 15:46:34 2014 From: k12ltsp at rwcinc.net (Patrick Fleming) Date: Mon, 29 Dec 2014 08:46:34 -0700 Subject: [K12OSN] : login user is root In-Reply-To: <1419287979.22632.100.camel@server1.eazylivin.net> References: <1419287979.22632.100.camel@server1.eazylivin.net> Message-ID: <54A1775A.9050602@rwcinc.net> Barry, You stated you are using the root public/private key for authentication. Do you have "standard" user keys? On 12/22/2014 03:39 PM, Barry R Cisna wrote: > Hi Johan, > > Yes selinux and iptables are both disabled at boot. > I have used ltsp/k12linux for anbout 11 years now so fairly familiar > with the configs,but each iteration of ltsp-server throws new curve > balls it goes without saying. > > > The reason for modding the sshd_config file was due to the fact that > root was failing the login for a standard user. > Without adding the public > keys for root to both server and client root,the standard user was > thrown back out to the login screen again. > Yes, i am familiar with doing the ltsp-update-sshkeys, along with > ltsp-update-kernels. > > Downside is now the login works,but a standard user,,,is root once > logged in. > > If you look at the log below,,you will see at top,,,a standard > user,,then directly below,root gets the go ahead from ssh? > Scouring through the ldm files, there is yet another ldm package that is > installed, with ltsp-server package ,,even since I done an install about > 6 months ago,that worked fine. > > I am sure it is of course something is haywire in the ldm init scripts > but don't have a clue were to look,,to troubleshoot. > > Also,i noticed randomly after adding the LDM_DEBUG_TERMINAL in the > lts.cong file,,i see randon "ldm: segfault at 8 ip. xxx" , in the popup > terminal on the client, > I found reference to this error as far back as two year ago,,but never > found what a real solution was or what caused this. > > > Thanks, > > Barry > > _______________________________________________ > K12OSN mailing list > K12OSN at redhat.com > https://www.redhat.com/mailman/listinfo/k12osn > For more info see >