[00:51] <CyberpunkZombie> hello all, can anyone recommend a good wireless pci card?
[06:21] <lordievader> Good morning
[08:29] <jamespage> coreycb: oh not nice - 1720887
[08:29] <jamespage> bug 1720887
[12:06] <coreycb> jamespage: is that on cpaelzer's radar?
[12:08] <coreycb> jamespage: fwding to him nonetheless
[14:31] <Jenshae> tomreyn and sarnold thank you for the help with hard drives and ZFS. I have managed to boot up a 4x 500GB RAID on one machine and 3x160GB RAID5 on another with Ubuntu server. The 160 machine is being used as a desktop.
[14:34] <Jenshae> I still need to configure the 500 one. At home, Ubuntu server with a desktop installed was giving me a lot of lag spikes, quirks and graphics failures, Xorg crashing. I have resorted to a standard SATA 500GB that is booting then it mounts a zpool of 3x 500GB SSHDs, which do seem to be improving my games performance and coding environments.
[15:03] <trippeh> "oh no", Slack is segfaulting on my Ubuntu 17.10
[15:08] <drab> Jenshae: were you doing root on zfs?
[15:08] <drab> I still have not dared to do that, seems a sketchy process
[15:09] <joelio> trippeh: wfm in ff, not using client
[15:09] <drab> also what SSHDs do you have? I'm running a bunch of standard HDs + a SSD for SLOG, but wondering if a few SSHDs would make a difference
[15:09] <soahccc> Is it normal that smart values go down? I mean the ones that normally only go up, do I have a self healing disk? got a bunch of these:  SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from 93 to 92
[15:10] <drab> soahccc: smart values normally go down afaik, at least a large chunk of them
[15:10] <drab> so in your case it's saying current value went down from 93 ot 92, when it gets to 5 your disk is toasted.
[15:11] <drab> alho ime I consider it to be replaced far before it gets to the threshold
[15:11] <drab> especially for key attributes like Realloc Sect
[15:12] <trippeh> ah hm. it seems to be crashing in glib, and glib did get upgraded earlier today.
[15:12] <soahccc> drab: well the disk had a very high Raw_Read_Error_Rate (65 million) but I figured this value is BS for most disk vendors. I let the provider check the disk, they said no error but I don't quite believe that. Smart long test goes through but the IO issues speak another language :/
[15:14] <drab> soahccc: I'd agree on Raw_read error to be BS, most stuff I read when I was trying to figure smart out said the same. normally it's only 3 or 4 attribue that's worth paying attention to and that's not one of them
[15:14] <drab> to be perfectly honest, unless it's some extreme case, I take all smart values with a bag, not a grain, of salt
[15:14] <soahccc> at least arguably sda (0 realloc) is way better of than sdb (325 reallocated sectors count)
[15:15] <trippeh> joelio: I'm using the electron clusterfuck. So I guess I'll be on the web thing for a bit. :)
[15:16] <soahccc> drab: the weird thing is that IO is very slow (e.g. database is waiting for IO a lot) and I'm guessing it's due to mdadm and one disk kinda dying
[15:16] <Jenshae> drab First step was, normal Ubuntu on normal 500GB Sata drive, pure magnetic.
[15:16] <Jenshae> Then I installed ZFS, just with apt install zfs
[15:17] <Jenshae> From there, I did a zfs create raidz /dev/disk/by-id/(x3)
[15:18] <Jenshae> Then using just used create to make folders and zfs mountpoint=/home/user/steampath/steamapps pool/steamapps
[15:18] <Jenshae> I hope that is enough for you to find your way, giving you a rough guide from memory
[15:19] <Jenshae> You need to use UUIDs with ZFS or it can get a bit hinky it seems.
[15:19] <drab> thanks, I have zfs going on several boxes, the question was about root on zfs
[15:19] <drab> which sounds like you're not using
[15:19] <Jenshae> I did use sudo -i to do it all, yes.
[15:19] <drab> k, thanks
[15:20] <Jenshae> What I wanted to do and couldn't manage was getting grub to boot the pool and run everything off it.
[15:21] <drab> soahccc: if you can afford it I'd replace the drive. most ppl I've talked about this with seem to replace the drive at around 100 tops, so 325 is pretty bad if you take their thresholds
[15:22] <soahccc> drab: yeah I'm going to monitor these counts for a couple of days and give that to my provider so I get the replacement for free :D
[15:24] <Jenshae> Sometimes it is fun to see how far something can go before it breaks completely ;)
[15:24] <Jenshae> Just have backups.
[15:27] <joelio> trippeh: yea, never understood that electron stuff tbh, there's already a browser on the machine! :)
[15:28] <drab> but but, it's a desktop app, you know, like, a desktop app, desktop apps are cool
[15:30] <trippeh> but I hate having free memory
[15:30] <trippeh> ;)
[15:30] <drab> lol
[15:30] <drab> take some sticks out and send them over :P
[15:48] <Jenshae> It sounds obvious but I found out this year that the benefits of 4x4GB are better than 2x8GB RAM sticks.
[16:00] <Jenshae> Ciao o7
[16:10] <soahccc> Hehe I think this is going way faster than thought, I'm at 340 (+15) Reallocated_Sector_Ct already... oh one more 341 ._.
[18:07] <trajik> Is there any trick to getting static ip configured in Ubuntu 17.10 Server?  Do you have to use netplan, or /etc/network/interfaces still works?
[18:08] <Epx998> Is there an apt repo that houses packages from https://packages.ubuntu.com/trusty-updates/debian-installer/ ?
[18:16] <maxb> Epx998: Um, the main Ubuntu archive itself?
[18:21] <drab> Epx998: I have "main/debian-installer" in my debmirror script and like maxb said it comes from the main ubuntu archive itself
[18:23] <Epx998> hmm
[18:26] <Epx998> and now my ixgbe driver wont compile buh
[19:10] <Village> Hello Guys, whats packages can be simulate with this python2-gevent python2-psutil ?
[19:19] <nacc> Village: can you rephrase your questio?
[19:19] <Village> nacc, ok
[19:19] <Village> i try sudo apt-get install python2-gevent python2-psutil
[19:20] <Village> and get error that this packages not existed
[19:20] <Village> its normaly?
[19:20] <nacc> Village: what versio of ubuntu?
[19:20] <nacc> Village: and yes, those packages don't exist on Ubuntu
[19:20] <sarnold> all the python2 versions of packages are named 'python-foo' and the python3 versions are named 'python3-foo'
[19:21] <Village> nacc, 16.04 (64bit)
[19:21] <nacc> Village: then what sarnold said
[19:21] <sarnold> it'd have saved everyone a load of trouble if they had used 'boa' or 'constrictor' or 'mamba' or something rather than 'python3' but what are you going to do? :(
[19:22] <Village> So python-foo isntalls al phyton2 packages?
[19:22] <sarnold> well, no, but if you want gevent for python2 then you install the 'python-gevent' package
[19:23] <Village> and what about psutil ?
[19:23] <sarnold> same thing, python-psutil
[19:24] <sarnold> try running 'apt-cache search python psutil' and see the output :)
[19:24] <Village> Ok, thank you Guys, what i need know now i know
[19:25] <Village> python-foo package does not exist
[19:26] <Village> seems like i not understand you good
[19:26] <nacc> Village: that was just an example, there is no python package named foo
[19:27] <Village> understand now this, nacc, ok
[19:27] <Village> good luck, guys,until
[19:28] <sarnold> Village: "foo", "bar", and "baz" are often used as stand-ins for real things
[19:28] <Village> now i know:)
[19:29] <sarnold> http://catb.org/jargon/html/M/metasyntactic-variable.html
[19:29] <Village> you light me
[19:48] <nacc> rbasak: fyi, glibc 2.19-13ubuntu1 has a patch that doesn't apply (quilt push fails). `pull-lp-source` of the same also fails. I think this relates to historic fuzz allowance, but not 100%. But I also can't recall what we decided to do to work around this
[20:19] <Epx998> is it possible to prevent a kernel upgrade after a install, so that the final kernel is the same as the installer?
[20:20] <nacc> Epx998: you'd need to update evenntually anyways?
[20:20] <Epx998> not nessessarily
[20:20] <Epx998> the ixgbe driver all of a sudden is failing to compile on fresh ubuntu images
[20:22] <nacc> Epx998: i mean, for security purposes, you do want to
[20:22] <nacc> isn't the ixgbe driver upstream?
[20:22] <Epx998> right, but still - not nessessarily
[20:22] <Epx998> and no its not
[20:22] <nacc> uh ... are you sure? apt-file says it is
[20:22] <Epx998> what version in the apt-file?
[20:22] <nacc> net/ethernet/intel/ixgbe/ixgbe.ko
[20:23] <Epx998> right but what version
[20:23] <nacc> I dunno
[20:23] <Epx998> 3.1.x something oro ther
[20:23] <nacc> but you said it was't upstream
[20:23] <nacc> it is.
[20:23] <Epx998> intel is on 5.2.x
[20:23] <Epx998> newer intel gbe cards dont work with ubuntu out the box
[20:24] <nacc> version=5.1.0-k
[20:24] <nacc> that's on 17.10
[20:24] <nacc> (4.13 base kernel)
[20:24] <Epx998> but on 14 and 16 its the old driver
[20:24] <nacc> soudns like a crappy vendor :)
[20:24] <trippeh> the version numbers are mostly just confusing
[20:24] <nacc> not sure why you'd think brand new hardware would work on an OS that is 4 years old
[20:24] <nacc> even with HWE
[20:25] <Epx998> no reason to not ship with an updated driver
[20:25] <Epx998> not all code is always built on the latest and greatest either
[20:25]  * nacc doesn't have time for this
[20:25] <Epx998> just saying ;P
[20:25] <trippeh> the linux mainline ixgbe driver tends to be more or less in sync with the intel one at the time of release
[20:26] <Epx998> trippeh: intel x550's dont work out the box with 14 or 16, shrug
[20:26] <trippeh> intel is just mostly lazy about updating the in-kernel version string
[20:26] <trippeh> Epx998: yes - at the time of release beeing the key point here
[20:27] <Epx998> i like ubuntu, but we dont have these problems in our centos farm
[20:28] <trippeh> yes, it is easier for intel to target ancient kernels with their out-of-tree driver :)
[20:29] <Epx998> our version of ubuntu is dictated by google I think, for our mobile stuff that uses android.
[20:29] <Epx998> not like my team personally wants to run these old releases
[20:32] <trippeh> did the out-of-tree driver stop building on newer 16.04 point releases, is that what you are saying?
[20:32] <trippeh> because x550 is supported out of the box on say 17.04
[20:33] <Epx998> thats great, but doesnt help on this farm im forced to run 12/14 on :D
[20:33] <Epx998> hmm gives me an ide tho
[20:33] <nacc> uh, run a modern OS as the host, and use VMs/containers?
[20:33] <trippeh> 12 is EOL though ;)
[20:33] <nacc> and that
[20:34] <Epx998> oh i know - its frigging silly
[20:40] <trippeh> if the out-of-tree driver is not building properly, you may be missing some header package for the newer images or intel needs to fix their release
[20:41] <trippeh> pastebin the error?
[20:46] <Epx998> it worked eariler, not sure what has changed.
[20:47] <Epx998> https://gist.github.com/anonymous/09b14e69e2f51d45f9061c65c977c004
[20:50] <trippeh> right, driver is def not expecting that kernel version
[20:50] <trippeh> seems like a poke intel problem :p
[20:50] <Epx998> ok so its something i am doing when i downgrade the kernel
[20:52] <Epx998> id just stick a updated kernel on the netboot installer, but that hasnt worked for me yet
[20:55] <rbasak> nacc: worst case: unless there's an easier way, we can apply (package, version) patching again.
[20:59] <Epx998> yeah its the downgraded kernel hmm
[22:05] <nacc> rbasak: yeah, i could recall if we had a different workaround than source patching for dealign with patches-applied failing
[22:06] <rbasak> I don't remember. I'm open to any better way :)
[22:07] <nacc> rbasak: well, we had talked about skipping patches-applied that don't apply
[22:07] <rbasak> Yeah
[22:07] <nacc> rbasak: which would lead to breaks in the history
[22:07] <nacc> but if we dont' have publishig parents anymore
[22:07] <rbasak> Maybe an opportunity to see if the history correctly resumes again?
[22:07] <nacc> that is a little less relevant
[22:07] <nacc> yeah
[22:07] <rbasak> If so, I don't think I particularly mind if we leave a hole in history or patch the source.
[22:07] <rbasak> I suppose for hash stability we can't change it later.
[22:08] <rbasak> So perhaps patching the source would be inconsistent with that.
[22:08] <nacc> rbasak: yeah, we just need to decide -- it feels weird to patch the source for a behavior change in dpkg (presumably)
[22:08] <rbasak> The more general issue will be a constant matter for us to deal with I think - changes in dpkg or related tooling that cause historical imports to behave differently.
[22:09] <nacc> yeah
[22:09] <rbasak> (whether by failing where it previously succeeded, succeeding where it previously failed, or changing the import result)
[22:09] <rbasak> All of those will mutate the hashes.
[22:09] <nacc> it is technically only valid to 'build' somethig in the release in which it built, right?
[22:09] <nacc> (where source extraction is just a pre-step to building)
[22:09] <rbasak> I think I have a bug on noting the "build" used to try and stabilise that.
[22:10] <rbasak> I hadn't thought of that, but I suppose that's the expectation that Debian and Ubuntu both try to enforce, yes.
[22:10] <nacc> well, what is technically nice is we *can* carry every dpkg version i the snap :)
[22:10] <rbasak> (and rarely further)
[22:10] <nacc> it's a bit madness
[22:10] <nacc> but it's technically possible for the bits we use (dpkg-source)
[22:10] <nacc> getting the build-deps right would be tricky, though
[22:10] <rbasak> Building really old versions may prove difficult too.
[22:11] <nacc> yeah
[22:11] <nacc> i mean it's possible, it may not work :)
[22:11] <rbasak> :)
[22:11] <rbasak> My feeling is that it's probably not worth it.
[22:11] <nacc> for now, let me see how it goes to skip a patches-applied failure
[22:11] <rbasak> I would like to log in the commit message what was used, though, so that we can reproduce it later.
[22:11] <nacc> and see how glibc at least looks
[22:11] <nacc> yeah
[22:11] <nacc> you mean like a dpkg version?
[22:11]  * rbasak heads for bed
[22:11] <nacc> rbasak: have a good evening
[22:11] <rbasak> Not just the dpkg version, but the everything version.
[22:12] <rbasak> Which might be better described as a snap version, for example, with separate tooling to be able to reproduce the snap version's build dependencies so we can later rebuild an equivalent snap.
[22:12] <rbasak> snap needs reproducible build support :)
[22:13] <nacc> heh, yeah well that's a whole other topic, rbasak :)
[22:35] <Village> Good evening,
[22:35] <Village> what's can be that i can't user sudo command?
[22:36] <Village> sudo: /etc/sudoers is owned by uid 1001, should be 0
[22:36] <Village> sudo: no valid sudoers sources found, quitting
[22:36] <Village> sudo: unable to initialize policy plugin
[22:38] <nacc> Village: pretty explicit error message there
[22:39] <Village> how fix it?
[22:39] <Village> maybe i ser chown -R for other user
[22:40] <Village> and other user cant use sudo
[22:40] <Village> how fix it you don't know?
[22:41] <nacc> Village: why is /etc/sudoers owned by 1001?
[22:42] <Village> i don't know what is 1001 but i use command with root chown -R User /etc/
[22:42] <genii> Ouch
[22:43] <nacc> Village: that was not very smart on your part
[22:43] <sarnold> ALWAYS use 'visudo' to edit the sudoers file
[22:43] <sarnold> NEVER use anything else
[22:43] <genii> A reinstall will be required.
[22:43] <genii> sarnold: He didn't edit it, he chowned it
[22:43] <Village> Ok, from now i know that need set chown only folder what you need now father folders
[22:44] <nacc> Village: I really cant' understand what you're writing
[22:44] <sarnold> holy cow .. chown -R user /etc/ .... yeah. definitely a re-install will be your easiest solution.
[22:44] <nacc> Village: you should not be chown'ing any system directories
[22:44] <genii> If you just boot to recovery and chown it back to root, there are various ones in there that normally are not owned by root. so a reinstall is best
[22:45] <nacc> yeah, i would also recommend a reinstall
[22:45] <nacc> and perhaps taking some sysadmin-y courses
[22:45] <Village> nacc, i use FTP and primary FTP user (ex. User), so sometimes need touch folders with via ftp
[22:45] <nacc> (that's not meant as derisive, Village, but it should really be obvious why you should not have done what you did)
[22:45] <nacc> Village:  you have no reason for *anyone* to ftp into /etc
[22:46] <nacc> might as well throw your machine into the trash
[22:46] <nacc> (now i'm being derisive)
[22:46] <sarnold> hehe
[22:46] <Village> hm..
[22:46] <Village> so dolution reinastall ubuntu
[22:47] <sarnold> yes
[22:47] <sarnold> and once you do, _please_ figure out a better way to administer the machine than FTP. Please. PLEASE. :)
[22:47] <Village> but if i boot it too rescue mode and chown -R root /etc/
[22:48] <sarnold> you could either spend an hour comparing ls -laR output on two machines and running a hundred chmod commands
[22:48] <sarnold> or you could just reinstall it and be sure it's configured correctly from the start
[22:48] <Village> oh, it's need time:/
[22:49] <Village> i first anyway try boot rescue mode and chown -R root /etc/
[22:50] <nacc> Village: as you've been told, that is also wrong.
[22:50] <nacc> Village: please listen to us and reisntall your machine
[22:50] <nacc> and then spend some time learning why a) administering your machine with FTP is incredibly wrong and b) why doing any kind of recursive chown in system directories could break things.
[22:51] <sarnold> actually, this might not be so bad
[22:51] <sarnold> here's the list of things in my /etc/ that aren't root:root http://paste.ubuntu.com/25676213/
[22:51] <genii> What might also work is in recovery, mount read-write, make a list of all the packages currently installed on your system, then do a reinstall on all those packages
[22:52] <sarnold> who knows what you had on _your_ machine, but this list is way smaller than I expected.
[22:53] <genii> Notably, the cups dir should be group lp, and shadow file and gshadow file to group shadow
[22:53] <Village> half day i install from zero, and now again
[22:53] <Village> i need tea and smoke el cigarette
[22:54] <Village> and thank you guys, need reinstall server
[22:54] <sarnold> good luck Village :)
[22:54] <Village> :) Thank you, Guys
[22:55] <nacc> rbasak: looks like it is able to move ahead with the just proposed MP (for review, not merging yet)
[23:01] <nacc> mdeslaur: do you want me to prepare an update for php7.0 to address https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-php-could-allow-for-arbitrary-code-execution_2017-093/ by bumping to 7.0.24?
[23:01] <nacc> mdeslaur: possibly you're already on it
[23:15] <drab> urm, they say test everything with virtual machines, it'll make things easier...
[23:15]  * drab shrugs
[23:16] <drab> for whatever reason ssh works from host to lxc container and to virtual box VM on the same desktop
[23:17] <drab> and viceversa
[23:17] <drab> ping works between vbox and lxc, but ssh does not
[23:17] <drab> but vbox has its if set up on the same bridge lxc is, hence the ping working
[23:24] <tafa2> so I added an extra source/ppa, when I delete it from sources.d on login ubuntu tells me there are 44 packages for me to update - these were obviously on the repo I deleted, since apt list upgradable now returns nothing. How can I clear this?
[23:25] <sarnold> tafa2: the ppa-purge package may help
[23:25] <tafa2> .google ppa-purge
[23:26] <tafa2> thanks sarnold
[23:26] <sarnold> tafa2: if you're sure there's no overlap between the ppa packages and the archive-provided packages, you can just delete the lists in /var/lib/apt/lists/
[23:27] <tafa2> cool!
[23:27] <tafa2> basically I've got a custom repo to install older PHP versions
[23:27] <tafa2> but it's also got newer php versions
[23:27] <tafa2> Is there a way for me to tell it to ignore those packages without having to type them all out individually?
[23:28] <tafa2> I suspect just removing it is easier - php 5.3 isn't going to get an update anytime soon I don't think.
[23:32] <tafa2> sarnold ppa purge removes all installed packages as well haha
[23:32] <tafa2> glad i ran that on a test system first.... phoooooo
[23:38] <drab> this is the weirdest thing...
[23:38] <drab> tcpdump shows SYNs making it on both ends and back
[23:38] <drab> but nothing else
[23:38] <drab> it's like never completing the TCP handshake