=== STiK is now known as iTrollU === iTrollU is now known as STiK === STiK is now known as iTrollU === iTrollU is now known as STiK [07:01] Good morning. [11:07] 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] 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] 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] cenobyte: you should check /var/log/syslog and /var/log/Xorg.0.log.old [11:14] to find some hints which could help to file a bug report [11:16] ah, yes there's a backtrace in Xorg.0.log.old! [11:17] thanks, I had only checked syslog [12:08] Hi folks === brainwash_ is now known as brainwash [15:20] cenobyte: i'm running 14.10 and i've never seen that [15:20] i haven't done a lot of testing yet though === om26er is now known as om26er|dinner [16:11] chrs_: I'm testing it on an iMac, could be something to do with my hardware I guess? [16:11] will be filing a bug report over the weekend anyway [16:46] In Utopic, wpa-supplicant is back to not playing nice with WPA2 Enterprise systems... [16:51] i have intermittent wifi problems too on wpa2 personal === om26er|dinner is now known as om26er [16:54] i want to file a bug report for a trackpad issue i'm having [16:54] it doesn't work after hibernate [16:54] how do i go about filing a report or something? [16:56] chrs_: ubuntu-bug linux; would seem like the reasonable package to choose initially [16:57] i think it's an issue with the trackpad driver [16:58] elantech? or something [16:58] i dunno, i don't have the machine in front of me now [16:59] https://bugs.launchpad.net/ubuntu/+source/linux [16:59] ? [17:01] well, filling out a bug report on that site seems pretty straightfoward [17:01] 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] ah, nice [21:12] 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] arpd, why are you using a development rather than a long term? [21:16] bubbasaure: because I wanted to test it out [21:16] I haven't found much wrong with it just yet, but what I have I reported. bubbasaure, why is that important? [21:17] 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] 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] 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] Thus, as I said, I don't think this is a utopic specific issue. [21:23] arpd: I've never seen ssh sessions refused sudo if the user is in the sudoers file. [21:24] 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] Ypur* [21:25] arpd: on the remote side does "groups" show "sudo" and/or "adm" ? [21:25] no TJ- [21:25] The user is not in either adm or sudo [21:26] bubbasaure: what the hell are you talking about? What reason have you got to attack my character? [21:26] 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] As you see any good help is on this channel as wel [21:26] yeah TJ-, whilst I was on my machine earlier today, I had no problems using it [21:27] So either installing openssh-server has removed / modified /ec/sudoers, or (less likely) modified my user's groups [21:27] arpd: And was that a regular multi-user boot, not a single-user / Recovery boot? [21:27] this is the only user on the machine, and the user was created at installation time [21:27] regular multi-user boot [21:27] arpd: Then I think you've found a bug :) [21:28] TJ-: so the default installation adds a user to a group or /etc/sudoers? [21:28] s/so/so does/ [21:28] arpd: the first user is supposed to be included in the sudo group, if I recall correctly [21:29] TJ-: right, but that doesn't make sense... After installing openssh-server, I could edit /etc/ssh/sshd_config [21:29] arpd: how was the installation done? From the Desktop or Server ISO, or a debootstrap, or something else? [21:29] 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] TJ-: debootstrap [21:30] 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] TJ-: I'm not sure, I followed a guide on ubuntu.org, I imagine it would have been apt-get [21:31] I don't remember using tasksel [21:31] 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] 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] arpd: Have you done a dpkg-reconfigure on anything/ [21:32] So TJ- are you saying _any_ user has sudo priviledges when done from a local tty? [21:32] TJ-: let me check my history [21:33] TJ-: No, I haven't done a dpkg-reconfigure [21:33] 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] 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] (in those active terminal sessions, not new ones) [21:34] arpd: If their sudo timestamp file was still valid, yes, I think they would, since group membership only changes on log-out [21:35] right, my machine has an uptime (login included) of several weeks [21:35] 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] (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] so it's probably too late to even find out what caused this.. [21:38] 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] arpd: without privileges, not that I can think of, unless one of those session is running under 'screen' [21:40] TJ-: I wish, since I started using a tiling window manager I stopped using a terminal multiplexer [21:41] TJ-: perhaps I can find a 0day floating around :) [21:41] arpd: I hope not :) [21:42] arpd: any vnc server running? [21:42] TJ-: let me check [21:43] TJ-: ah, nope, I only have vncviewer installed for working from home [21:44] arpd: I can't think of any other way unless you set a root password [21:45] TJ-: nope, I didn't :( [21:45] going to have to wait until I'm back on Sunday then, bollocks.