[07:01] <lordievader> Good morning.
[11:07] <cenobyte> anyone know if regular (~2 min intervals) 100% CPU spikes in /usr/bin/X are to be expected at the moment in 14.10?
[11:08] <cenobyte> I'm using nouveau driver as nvidia-current causes the whole system to freeze when it reaches lightdm / gdm / kdm (I've tried all three)
[11:10] <cenobyte> when it gets into that state it doesn't respond to magic sysrq commands, or ctrl-alt-f[1-7], and can't SSH to it either so I have to do a hard reboot
[11:13] <brainwash> cenobyte: you should check /var/log/syslog and /var/log/Xorg.0.log.old
[11:14] <brainwash> to find some hints which could help to file a bug report
[11:16] <cenobyte> ah, yes there's a backtrace in Xorg.0.log.old!
[11:17] <cenobyte> thanks, I had only checked syslog
[12:08] <BluesKaj> Hi folks
[15:20] <chrs_> cenobyte: i'm running 14.10 and i've never seen that
[15:20] <chrs_> i haven't done a lot of testing yet though
[16:11] <cenobyte> chrs_: I'm testing it on an iMac, could be something to do with my hardware I guess?
[16:11] <cenobyte> will be filing a bug report over the weekend anyway
[16:46] <SonikkuAmerica> In Utopic, wpa-supplicant is back to not playing nice with WPA2 Enterprise systems...
[16:51] <chrs_> i have intermittent wifi problems too on wpa2 personal
[16:54] <chrs_> i want to file a bug report for a trackpad issue i'm having
[16:54] <chrs_> it doesn't work after hibernate
[16:54] <chrs_> how do i go about filing a report or something?
[16:56] <trism> chrs_: ubuntu-bug linux; would seem like the reasonable package to choose initially
[16:57] <chrs_> i think it's an issue with the trackpad driver
[16:58] <chrs_> elantech? or something
[16:58] <chrs_> i dunno, i don't have the machine in front of me now
[16:59] <chrs_> https://bugs.launchpad.net/ubuntu/+source/linux
[16:59] <chrs_> ?
[17:01] <chrs_> well, filling out a bug report on that site seems pretty straightfoward
[17:01] <trism> chrs_: yes that would be the package, might want to look around at the bugs already there, but when you want to file one you can actually type: ubuntu-bug linux; in the terminal on the machine and it will collect info and walk you through filing the bug
[17:01] <chrs_> ah, nice
[21:12] <arpd> So I installed openssh-server, and just connected, but I cannot use sudo (user is not in sudoers file), but I could do so when I was physically at my machine, and not connected over ssh. Is there something I can do from my now remote session? I have several local terminal sessions still active (under the same username), can I reroute any of those perhaps? I am using ubuntu utopic unicorn preview;
[21:14] <bubbasaure> arpd, why are you using a development rather than a long term?
[21:16] <arpd> bubbasaure: because I wanted to test it out
[21:16] <arpd> I haven't found much wrong with it just yet, but what I have I reported. bubbasaure, why is that important?
[21:17] <arpd> anyway, enough of a character assessment, does anyone know of something reasonable I can do, or am I SOL until I get back home on Sunday?
[21:18] <bubbasaure> Than this is the correct channel an arbitrary issue that you think is okay on the main channel is the burden you enjoy by testing.
[21:22] <arpd> bubbasaure: I'm not sure I understand what you're saying... From what I can tell, (which is not much as no one appears to know or has said anything) Ubuntu installations do _not_ add the 'installation' user to the 'sudo' group or /etc/sudoers and instead allow access based on whether sudo was executed locally or not
[21:22] <arpd> Thus, as I said, I don't think this is a utopic specific issue.
[21:23] <TJ-> arpd: I've never seen ssh sessions refused sudo if the user is in the sudoers file.
[21:24] <bubbasaure> That is not tour call you run it on it, your are just looking beyond the basic norms to your own selfish needs.
[21:24] <bubbasaure> Ypur*
[21:25] <TJ-> arpd: on the remote side does "groups" show "sudo" and/or "adm" ?
[21:25] <arpd> no TJ-
[21:25] <arpd> The user is not in either adm or sudo
[21:26] <arpd> bubbasaure: what the hell are you talking about? What reason have you got to attack my character?
[21:26] <TJ-> arpd: OK, so definitely not in the groups, which explains why that is happening. But you're saying that 'sudo ...' works for the same user at the VTs or GUI ?
[21:26] <bubbasaure> As you see any good help is on this channel as wel
[21:26] <arpd> yeah TJ-, whilst I was on my machine earlier today, I had no problems using it
[21:27] <arpd> So either installing openssh-server has removed / modified /ec/sudoers, or (less likely) modified my user's groups
[21:27] <TJ-> arpd: And was that a regular multi-user boot, not a single-user / Recovery boot?
[21:27] <arpd> this is the only user on the machine, and the user was created at installation time
[21:27] <arpd> regular multi-user boot
[21:27] <TJ-> arpd: Then I think you've found a bug :)
[21:28] <arpd> TJ-: so the default installation adds a user to a group or /etc/sudoers?
[21:28] <arpd> s/so/so does/
[21:28] <TJ-> arpd: the first user is supposed to be included in the sudo group, if I recall correctly
[21:29] <arpd> TJ-: right, but that doesn't make sense... After installing openssh-server, I could edit /etc/ssh/sshd_config
[21:29] <TJ-> arpd: how was the installation done? From the Desktop or Server ISO, or a debootstrap, or something else?
[21:29] <arpd> Ah, but that would have been from a shell that was logged in while the user was still in that group, is that how it works?
[21:29] <arpd> TJ-: debootstrap
[21:30] <TJ-> arpd: Hmmm... I suspect the system is missing some core packages that configure this... did you use "tasksel" or "apt-get" to install the base packages?
[21:31] <arpd> TJ-: I'm not sure, I followed a guide on ubuntu.org, I imagine it would have been apt-get
[21:31] <arpd> I don't remember using tasksel
[21:31] <arpd> But TJ-, that configure what? I have been using this installation for several weeks now, and have had sudo access the entire time
[21:32] <TJ-> arpd: The installer is responsible for adding the initial user to the 'sudo' group; if you created the user manually it is likely you missed that step
[21:32] <TJ-> arpd: Have you done a dpkg-reconfigure on anything/
[21:32] <arpd> So TJ- are you saying _any_ user has sudo priviledges when done from a local tty?
[21:32] <arpd> TJ-: let me check my history
[21:33] <arpd> TJ-: No, I haven't done a dpkg-reconfigure
[21:33] <TJ-> arpd: No, i'm not saying that. There should be no difference between local and ssh unless the ssh users are forced to use a restricted shell
[21:34] <arpd> TJ-: that is very strange then. If I were to remove a user from the sudo group, but they still had terminal sessions active from when they were in it, would they still be able to use it?
[21:34] <arpd> (in those active terminal sessions, not new ones)
[21:34] <TJ-> arpd: If their sudo timestamp file was still valid, yes, I think they would, since group membership only changes on log-out
[21:35] <arpd> right, my machine has an uptime (login included) of several weeks
[21:35] <arpd> so anything I've installed sine then might have done this, and I might only be noticing it now I am logging in remotely
[21:35] <arpd> (i magine virtual terminal sessions from a window manager will use the 'window manager' login, i.e. not update group membership until they log out'
[21:36] <arpd> so it's probably too late to even find out what caused this..
[21:38] <arpd> right, so failing there being anyway to find out what caused this, is there any way I can recover remotely TJ-? Can I hook in to my active 'local' sessions from my remote session without su access?
[21:40] <TJ-> arpd: without privileges, not that I can think of, unless one of those session is running under 'screen'
[21:40] <arpd> TJ-: I wish, since I started using a tiling window manager I stopped using a terminal multiplexer
[21:41] <arpd> TJ-: perhaps I can find a 0day floating around :)
[21:41] <TJ-> arpd: I hope not :)
[21:42] <TJ-> arpd: any vnc server running?
[21:42] <arpd> TJ-: let me check
[21:43] <arpd> TJ-: ah, nope, I only have vncviewer installed for working from home
[21:44] <TJ-> arpd: I can't think of any other way unless you set a root password
[21:45] <arpd> TJ-: nope, I didn't :(
[21:45] <arpd> going to have to wait until I'm back on Sunday then, bollocks.