[04:14] <lotuspsychje> good morning
[07:05] <lordievader> Good morning
[07:49] <ducasse> good morning
[14:32] <pragmaticenigma> hggdh: you mean the fact that they've been doing it for more than 4 hours isn't enough reason to block them?
[14:33] <oerheks> he avoida a ban by using multiple ways of connection, weak tor config
[14:34] <hggdh> oerheks: banned by $a, not connection address/type
[14:34] <pragmaticenigma> I'm guessing with the somewhat higher internet usage.. tor is really going to be flakey
[14:35] <oerheks> thanks hggdh :-)
[14:35] <akem> Will "service" (to list services) be removed at some point? also i wonder why it is so slow to list.
[14:36] <pragmaticenigma> Isn't that something server side?
[14:39] <akem> pragmaticenigma, Hm, you mean that to me? It's all local AFAIK, i was trying to list running services, first using "service --status-all" and it's very slow, but "systemctl list-unit-files" is instant.
[14:39] <akem> Of course much more infos with systemctl.
[14:39] <pragmaticenigma> akem: oh... you mean on your machine... didn't realize the topic of the conversation switched
[14:40] <akem> Yeah.
[14:42] <akem> It is a bit faster now, but first time i tried, it was waiting on each line, strange.
[14:42] <pragmaticenigma> indexing perhaps?
[14:45] <akem> Yeah, i don't know.
[15:23] <pragmaticenigma> ChadTaljaardt: First and foremost, your company should be running daily backups of their production systems. If they're not doing that much, then they are setting themselves up for major single point of failure.
[15:24] <pragmaticenigma> the backups are the first line of defense for restore after system crashes, bad updates, etc
[15:24] <pragmaticenigma> and they should be keeping several backups around, in case an update takes a few days to manifest a problem
[15:24] <akem> If they want you to compile everything, switch to Gentoo it will be easier maybe :P
[15:24] <pragmaticenigma> akem: please don't
[15:25] <akem> Just joking.
[15:25] <oerheks> he worries about his 'production environment'  ???
[15:25] <oerheks> no testing setupo?
[15:25] <oerheks> lolz
[15:26] <ChadTaljaardt> We keep database backups every day and store them for 60 days if i recall correctly
[15:26] <pragmaticenigma> ChadTaljaardt: To make your company understand better... tell them that it takes more man hours and costs more money to take their proposed approach, when there are so many smaller more maintainable approaches
[15:27] <ChadTaljaardt> i dont think the comapany cares about that, they see it as a really high priority to make sure everything is version static
[15:27] <pragmaticenigma> also, all that stuff you mentioned, increases the chances of something breaking... not preventing
[15:27] <ChadTaljaardt> i just dont understand whats so bad about getting curl from apt..
[15:28] <oerheks> curl bad from apt?
[15:28] <oerheks> interesting..
[15:28] <pragmaticenigma> companies do many stupid things... but one they will pay attention to is their bottom line... they don't want to spend more money on a problem than they have to
[15:28] <ChadTaljaardt> i think their perspective is that if you download a specific version and compile it manually, there is no chance of something going wrong with it later on, as everything should be exactly the same
[15:29] <pragmaticenigma> and then they wonder why they got hacked because someone wasn't paying attention to a security update and didn't patch the servers
[15:30] <oerheks> ChadTaljaardt, if you are so sensitive, built it yourself then, i see no security risc building by ubuntu
[15:30] <ChadTaljaardt> Ive tried presenting that argument... they said getting the latest updates is a security risk
[15:30] <ChadTaljaardt> While - because this is essentially a temp solution until (hopefully) we go "docker", I can live with it,  I would point out that just pulling the "latest" version of even smaller widgets is a recipe for a) a bollocks when something unexpectedly gets broken (and sorry - sooner or later that will happen) and b) is a security hole as big as a very big one should the underlying widget codebase get compromised.   Its fine for Dev trees, as a
[15:30] <ChadTaljaardt>  "production" thing it rather less so...
[15:30] <ChadTaljaardt> thats what they said
[15:31] <oerheks> so, if you have no seperate testing pc, even your own builded packages can fail
[15:31] <oerheks> apt or make..
[15:31] <ChadTaljaardt> we do use a staging environement to test stuff
[15:32] <ChadTaljaardt> but we only update things like every 6 months or so
[15:32] <pragmaticenigma> ChadTaljaardt: Personally... I'd quit my job
[15:32] <oerheks> yeah, stay @127.0.0.1
[15:32] <ChadTaljaardt> bad time to quit lol, job market looks bad atm
[15:32] <pragmaticenigma> ChadTaljaardt: soon as they get hacked or something crashes... your butt is going to get fired... they're looking for a scape goat
[15:34] <ChadTaljaardt> problem is that the data hosted on the website is "highly sensitive"
[15:34] <ChadTaljaardt> so we need to have very very good security
[15:34] <ChadTaljaardt> such a dilemma..
[15:34] <pragmaticenigma> So they want to lower the security to make it more secure... oh that makes so much more sense /sarcasm
[15:35] <ChadTaljaardt> their argument is that newer versions of software can continue security holes, because it most likely hasn't been extensively tested and had time for people to look at it.
[15:35] <ChadTaljaardt> contain *
[15:36] <ChadTaljaardt> whereas older versions have had more time to be tested, thus more secure and more stable
[15:36] <ChadTaljaardt> -.-
[15:36] <pragmaticenigma> !latest | See this:
[15:37] <pragmaticenigma> Ubuntu already does that for you ChadTaljaardt ... they don't release the "latest" versions... they keep the version at the same version that was available at the time of release of the Ubuntu version
[15:37] <oerheks> a package gets tested before it gets green light...
[15:37] <ChadTaljaardt> already told them that..
[15:37] <ChadTaljaardt> got ignored
[15:37] <ChadTaljaardt> lol
[15:37] <pragmaticenigma> The updates that Canonical pushes out are patches against the existing and vulnerable version, they don't upgrade to the latest because of a hole or bug... they fix it
[15:38] <ChadTaljaardt> is that what you get when you do stuff like apt-get upgrade?
[15:38] <ChadTaljaardt> cause we arent allowed to do that
[15:38] <pragmaticenigma> Then I'm done with this exercise... As mentioned in main, the support channel will not support packages not provided through apt. That holds true for the channel and would probably hold true if your company had a support contract with canonical
[15:39] <pragmaticenigma> The volunteers rely on the documentation put out by the developers of ubuntu... when a person/group compiles their own, we have no idea what flags, customizations, etc, where done to the code. and wouldn't have the proper documentation to support it
[15:39] <ChadTaljaardt> well i got a call with them in 25 minutes to try argue the case for using apt.. so i wonder how this will go
[15:40] <pragmaticenigma> Oh my Tux! You guys are just begging to get hacked... your company is a very very sad company
[15:42] <pragmaticenigma> ChadTaljaardt: you can inform them... updates provided by canonical, within the support cycle of a release, do not push out the latest versions. They only focus on severe bug fixes and vulnerabilities. In the most rare of rare occassions is a new version release, but only when there is absolutely no way to fix the issue in the existing release.
[15:43] <ChadTaljaardt> when you say a new release and a fix in a pre-existing realease, does that mean that if you install the same version of a package, say curl, that the code used to run this could be different in both cases?
[15:43] <ChadTaljaardt> unless i am misunderstanding this
[15:43] <pragmaticenigma> And when such an event happens, there are notifications sent out through release notes and other channels to let customers and users know that such an update is being made. so companies have ample time to prepare and test before deployment
[15:44] <pragmaticenigma> Example: For Ubuntu 18.04 LTS, the version of curl I'm running on my machine is the same version that was available at install 2 years ago. Only thing that has been updated was for security vulnerabilities in that time. That is it
[15:45] <ChadTaljaardt> right okay, so the version number will change but itll only be minor version number changes, not major
[15:45] <pragmaticenigma> it won't necassarily be the minor version that changes... it might be a build number
[15:45] <pragmaticenigma> so sub of the sub minor version number
[15:46] <ChadTaljaardt> and if there are no security updates or major bug fixes, it'll be the original that was shipped with the os version
[15:46] <ChadTaljaardt> ahh okay
[15:46] <pragmaticenigma> that is correct ChadTaljaardt
[15:47] <ChadTaljaardt> i think they might listen if i say that, because their perspecitive is that any changes as long as its not a major change gets packaged and shipped..
[15:47] <pragmaticenigma> I'm a software developer myself... there is nothing worse than coding an application to leverage a system tool, only to have that tool change on you. It is one of the reasons that I have choosen Ubuntu over other distributions
[15:47] <ChadTaljaardt> tbh they just need to learn how this stuff works, dont think it should be me doing this lol
[15:47] <pragmaticenigma> darn right
[15:48] <ChadTaljaardt> yeah thats their fear, we used to install things like elasticsearch and when there was an update it would break the system, we have pinned the version of elasticsearch now, but because of that they want to pin absolutely everything
[15:48] <pragmaticenigma> the devs for Ubuntu, CentOS, RedHat, SuSE have been doing this for many many years... they all have similar philosophies when it comes to updates of software
[15:49] <pragmaticenigma> better is to pin the problematic package, terrible is to assume everything is doing that
[15:51] <ChadTaljaardt> yeah i proposed pinning the versions of all the stuff that is not within ubuntu, so like elasticsearch, rabbitmq, we have a custom python version (3.8) so thats pinned etc
[15:51] <ChadTaljaardt> but should leave things like autoconf and wget to just come from apt
[15:51] <pragmaticenigma> that sounds like the right approach to me
[15:52] <pragmaticenigma> from this conversation... what it sounds like to me is they got bit in the bum version chasing... now they're gun shy about everything
[15:52] <pragmaticenigma> I develop personally in python... I develop against version 3.6, even though most of my stuff is running on 3.7 and 3.8 machine
[16:05] <pragmaticenigma> littlekimmy... at it again...
[16:06] <oerheks> yes, a bad boy
[16:07] <oerheks> if people do not want to read, why reading in #u ?
[16:07] <pragmaticenigma> everything that comes up with a google search on their handle has someone telling them to leave
[16:08] <pragmaticenigma> and notice how ever time someone calls them out on it... they go silent... until they think I'm not looking
[16:08] <pragmaticenigma> or someone else that called them out for their behavior
[16:36] <ChadTaljaardt> woo..
[16:37] <ChadTaljaardt> convinced my team, they are on board with only pinning major packages we use like elasticsearch.. now i need to convince the CTO to allow us to run things like apt-get upgrade and not version pin everything
[16:37] <ChadTaljaardt> fun fun
[16:37] <daftykins> apt-get is pretty old school at this point fwiw, just apt now is enough :) saves on the ol' keystrokes
[16:38] <pragmaticenigma> agreed... apt helps simplify... apt-get is still better for automating stuff
[16:41] <pragmaticenigma> !info fglrx bionic
[16:42] <daftykins> how-so?
[16:42] <daftykins> definitely took a while for feature parity, i think the xenial one couldn't 'clean'
[16:44] <pragmaticenigma> I guess it came out of the man page: The `apt` command is meant to be pleasant for end users and does not need
[16:44] <pragmaticenigma>        to be backward compatible like apt-get(8).
[16:44] <oerheks> apt is superiour over apt-get
[16:45] <pragmaticenigma> I think where I got the apt-get for automatted purposes was the progress bar in apt (which can be turned off) could cause issues for applications trying to pull and interpret the output
[17:04] <ChadTaljaardt> pragmaticenigma do you know of a source which states that the ubuntu packages from apt are not the "latest"
[17:07] <pragmaticenigma> ChadTaljaardt: I'll see if I can find a place that it is explicately spelled out... for now it might be somewhere in these docs: https://ubuntu.com/server/docs
[17:07] <pragmaticenigma> https://ubuntu.com/server/docs/package-management
[17:09] <pragmaticenigma> I don't know where the source of our factoid came from
[17:09] <pragmaticenigma> !latest
[17:11] <ChadTaljaardt> yeah i tried googling for that term and it doesnt show anything except irc logs
[17:11] <daftykins> if people are version chasing, educate them how ridiculous it is
[17:11] <pragmaticenigma> hggdh: Do you happen to know the source of the !latest factoid
[17:12] <pragmaticenigma> daftykins: we just did that earlier in here
[17:12] <ChadTaljaardt> found this https://askubuntu.com/questions/151283/why-dont-the-ubuntu-repositories-have-the-latest-versions-of-software which tells it, but they want a more official source
[17:12] <ChadTaljaardt> lol
[17:13] <ChadTaljaardt> what is version chasing?
[17:13] <daftykins> when people think that a bigger number and the pursuit thereof is everything
[17:13] <pragmaticenigma> ChadTaljaardt: It's the opposite of what your company is trying to do
[17:14] <ChadTaljaardt> ahh so always wanting the latest and greatest of everything
[17:15] <lotuspsychje> ChadTaljaardt: latest doesnt mean greatest, thats the whole point
[17:16] <ChadTaljaardt> it was just tongue and cheek
[17:16] <ChadTaljaardt> im gonna get lunch, be back in a hour or so
[17:17] <ChadTaljaardt> take care :)
[17:17] <sarnold> hopefully helpful https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions https://www.debian.org/security/faq#version https://access.redhat.com/security/updates/backporting https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-update-backport.html
[17:19] <ChadTaljaardt> thanks sarnold
[17:19] <pragmaticenigma> ChadTaljaardt: White paper here: https://ubuntu.com/about/release-cycle
[17:19] <ChadTaljaardt> ill check it out
[17:21] <pragmaticenigma> ChadTaljaardt: in the link I sent, under the heading "Maintenance and security updates"
[17:21] <sarnold> pragmaticenigma: that's nice page
[17:22] <pragmaticenigma> BINGO! found it... same page ChadTaljaardt under the heading "Ubuntu kernel release cycle" second paragraph
[17:22] <pragmaticenigma> In general, all of the LTS kernel packages will use the same base version of the Linux kernel, for example, Ubuntu 18.04 LTS kernels typically used the 4.15 upstream Linux kernel as a base. Some cloud-specific kernels may use a newer version in order to benefit from improved mechanisms in performance or security that are material to that cloud. These kernels are all supported for the full life of their underlying LTS
[17:22] <pragmaticenigma> release.
[17:23] <ChadTaljaardt> thats only saying for the kernel though, not the packages in the apt?
[17:24] <ChadTaljaardt> unless im misunderstanding it
[17:26] <sarnold> cloud-specific kernels are weird
[17:27] <sarnold> https://kernel.ubuntu.com/sru/dashboards/web/kernel-stable-board.html
[17:27] <pragmaticenigma> I'm not an expert on this, the page as a whole is supposed to instill the confidence that Ubuntu is stable and things aren't going to shift beneath the feat of an organization trying to use the product
[17:27] <pragmaticenigma> *feet
[17:27] <TJ-> clouds tend to vaporise or rain down on you - remember that!
[17:27] <sarnold> lol
[17:28] <pragmaticenigma> ChadTaljaardt: Beyond what we can find, you might have to call https://canonical.com/contact-us
[17:31] <pragmaticenigma> ChadTaljaardt: https://wiki.ubuntu.com/LTS
[17:31] <TJ-> LTS == if we break it we might actually fix it
[17:31]  * lotuspsychje opens umbrella
[17:38] <hggdh> !-latest
[17:38] <hggdh> pragmaticenigma: ^
[17:39] <hggdh> or, you meant the raw factoid:
[17:39] <hggdh> !+latest
 Packages in Ubuntu may not be the latest. Ubuntu aims for stability, so "latest" may not be a good idea. Post-release updates are only considered if they are fixes for security vulnerabilities, high impact bug fixes, or unintrusive bug fixes with substantial benefit. See also !backports, !sru, and !ppa.
[17:43] <pragmaticenigma> hggdh: I mean the actual location of documentation that was used to create that factoid... like where in the Canonical/Ubuntu documentation does that message come from
[17:43] <pragmaticenigma> hggdh: as in citation
[17:43] <lotuspsychje> hggdh: ChadTaljaardt wanted an explain of why LTS has not latest packages
[17:46] <hggdh> oh. No, I do not know (anymore). But the reason is basic: stability. Same thing Red Hat, SUSE, Oracle, etc (even Debian) do: you need a stable image you can redeploy multiple times without wasting time to learn of new problems/issues/features
[17:47] <pragmaticenigma> at some point, that should make it's way into ubuntu.com's whitepapers as "fact" ... for now the only true reference I was able to find lives in a wiki
[17:47] <pragmaticenigma> I don't know what the process is for that
[17:49] <lotuspsychje> somthing to also think about, is when ubuntu serves latest snaps right from software choices, we get mixed systems with both stability and latest software
[17:49] <hggdh> I really do not know. It may well be that this is one of the "basic truths" that everybody assumes but very few (myself included) actually thought of documenting
[17:50] <oerheks> interesting conv. https://discourse.ubuntu.com/t/proposal-for-ubuntu-20-04lts/12969
[17:50] <oerheks> all we need is an #ubuntu-snap channel please
[17:51] <lotuspsychje> oerheks: one month to go..i assume things will be bit late for insert all those ideas
[17:51] <hggdh> lotuspsychje: yes, snaps can give a sysadmin headaches; most places I have been, snaps are only installed by the sysadmins (and they have to have an approved change request)
[17:52] <hggdh> oerheks: there is already #snappy
[17:53] <pragmaticenigma> hggdh: I think with Ubuntu evolving toward more enterprise level of products, it would be advantages to include that in their whitepapers and on the main site pages. Where content can't be modified freely by those with accounts.
[17:53] <lotuspsychje> oerheks: maybe 20.10 :p
[19:34] <rfm> Is there any reason to prefer UUID=blahblah over /dev/disk/by-uuid/blahblah in /etc/fstab?
[19:36] <lordcirth_> rfm, It's shorter and clearer, IMHO
[19:37] <daftykins> yeah critical file, reduce the character count imo
[19:44] <rfm> I noticed the 20.04(dev) installer now uses /dev/disk/by-uuid
[19:58] <jalepenoftw> Hi there! I've been working on an open source project (https://FreePN.com) for a few months and wanted to get some feedback! FreePN is a Linux-first (Ubuntu included) open-source peer-to-peer VPN project.
[19:58] <jalepenoftw> explanations for this and other common questions here: https://freepn.com/pages/faq.html)
[20:01] <akem> jalepenoftw, It's a nice idea, but it won't work for many of us.
[20:04] <akem> Here i'm using a VPN(NordVPN) because it's not logged and no-one is monitoring the connection. Now if i use FreePN, i can become some sort of exit node for other peers, and my output is monitored, so someone torrenting for example, my ISP would just think i am torrenting. And other peers maybe logged or monitored too.
[20:04] <daftykins> yeah that'd be in violation of most peoples ISP contract
[20:08] <jeremy31> Who reads?
[20:08] <jalepenoftw> So we actually allow you to choose what traffic you're comfortable carrying -- we give certain pre-selected categories you can choose from (think filesharing as an example), and if you basically 'check the box' for a given category, that traffic will be rerouted elsewhere / you won't act as an exit node for that category of traffic.
[20:12] <akem> Yeah. It's still a good project, i hope it will get some attention.
[20:16] <akem> I think the alternative is the darknet(Tor) but only if you stay on the encrypted network(onion), that way no one can tell what's going on. - but most people want things that are only available on clearnet OFC, and it's not usable ATM for torrenting.
[21:13] <oerheks> LLVM 10.0.0 Release (llvm.org)