[07:00] <smalls1> I'm having an issue with ipv6 as far as it not being able to bind to eth0 and filling log files to the tune of GB's. I have mitigated the disk usage by editing 
[07:00] <smalls1> /etc/systemd/journald.conf
[07:00] <smalls1> to limit the size of the files.
[07:00] <smalls1> upon login, I see this seemingly Relevant section 
[07:00] <smalls1>  https://pastebin.com/H8BUPGSR
[07:00] <smalls1> Also dmesg seems to provide:
[07:00] <smalls1> audit: type=1400 audit(1674610638.420:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=495 comm="apparmor_parser"
[07:00] <smalls1> I'm wondering if apparmor is preventing the successful binding to eth0. 
[07:00] <smalls1> I don't currently use ipv6 for anything, but I would like to resolve the issue/error.
[07:00] <smalls1> Any insights or suggestions are welcome. This is my first time with this issue.
[07:00] <smalls1> The system is currently hosted as a VPS if that provides any additional information.
[07:23] <frickler> smalls1: seems your network config is broken, for autoconfig you need a /64, but the log shows /96
[07:53] <smalls1> frickler: thank you for responding.  is this something I can change on my end? any reading material I can access to wrap my head around this? 
[08:02] <smalls1> perhaps netplan configuration adjustment?
[08:38] <frickler> smalls1: depends on where this is coming from. if your netplan config doesn't contain anything about IPv6 currently, adding "dhcp6: true" may help. otherwise you need to check with your VPS provider
[14:11] <teward> athos: i see a server triage discuss on a wontfix nginx bug from well over a year ago.  note Debian hasnt made the change either suggested by the bug regardless of Fedora or not (I would know, I'm a comaintainer in Debian)
[14:12] <teward> anything i should know?  (see bug #1666368)
[14:12] -ubottu:#ubuntu-server- Bug 1666368 in nginx (Ubuntu) "[Ubuntu 16.04] nginx won't start on boot while network does not up yet" [Undecided, Won't Fix] https://launchpad.net/bugs/1666368
[14:33] <athos> hey teward! Thanks for pinging on this one :)
[14:36] <athos> I just did not want to reply to that comment saying that "our position have not changed on this one" without discussing with the team and confirming the position did not change. I will remove the tag if you want to reply to that comment. Otherwise, I will reply after discussing it with the team later today
[14:48] <teward> athos: any chance we can get the 'team' discussion on that one to include me?  I know the Server Team has their own internal meetings, etc. but I'd like to put my two cents in
[14:48] <teward> teeeeechnically i'm not officially part of the paid server team but still keep nginx in my radar *heavily* xD
[14:50] <teward> my opinion is "stay with the systemd docs, unless Debian changes this" but I swear I've seen this request in Debian and it was won'tfixed
[14:51] <athos> easiest way would be to start a thread in ubuntu-server@lists.ubuntu.com and remove the tag, having the discussion in the mailing list. I can start the thread now if that works for you :)
[14:51] <teward> go right ahead
[14:51] <teward> also update your LP profile - freenode is now lIbera chat for ubuntu ;)
[14:51] <teward> *is nitpicky today*
[14:52] <athos> haha thx :)
[14:53] <teward> i saw your email about triage and why you put it on the list again
[14:54] <teward> i should point out though that this is one of those things where divergence from Debian just *adds* to the delta, it's a small delta but still
[14:56] <rbasak> FWIW, I don't want to make these changes as piecemeal delta. Either we do it across the distribution as a policy, or not at all.
[14:56] <athos> yeah... I wouldn't even call it a small delta, if applied, considering how this would change package behavior/service start process
[14:56] <teward> here's a key question: what're the other httpd packages doing
[14:56] <teward> apache2, lighttpd, etc.
[14:56] <teward> i think they're doing what we're doing now
[14:57] <teward> if we choose to change this for nginx then we would have to apply this in other httpds as well to match functionality, so that 'delta' is larger because it requires a distro wide change there
[14:57] <teward> and if Debian isn't doing it it makes me question whether we should
[14:57] <teward> not that it should be the only decider, but it's still a valid q
[14:58] <rbasak> I suggest that the point made at the bottom of https://devguide.python.org/documentation/style-guide/#audience is relevant here.
[14:59] <rbasak> "vocal category of reader who is looking for vindication for one of their programming errors"
[14:59] <teward> rbasak: so, treat this as a case of "this user is being obstinate with their opinions, so stay our ground hard and reiterate our decision from circa-2020"?
[15:00] <rbasak> IMHO, this has already been extensively discussed, and a random person hitting the issue is something we already knew would happen, and so doesn't really change anything.
[15:00] <teward> (I'm uncaffeinated, assume i'm saying things 'harder' than i mean)
[15:00] <rbasak> (nor does their vote)
[15:01] <teward> ack
[15:01] <rbasak> OTOH, I'm open to reconsideration if there's widespread consensus that something needs to change, but I don't see that here.
[15:01] <teward> agreed
[15:01] <teward> two or three people != wide consensus
[15:02] <teward> also i'd support this if nginx upstream had this in their systemd service in the tarball but they don't so.
[15:02] <teward> :P
[15:02] <rbasak> Some upstreams do, and it's still wrong. The distribution should have a consistent policy across all packages and stick to it.
[15:02] <rbasak> That way users know what they need to do if they want to customize.
[15:02] <teward> agreed
[15:03] <rbasak> Also see: https://discourse.ubuntu.com/t/spec-definition-of-an-online-system/27838/5
[15:03] <teward> then i think we're going to stick to our guns, and I'm happy to remove the tag and reiterate that the general consensus of the *distribution* is to follow SystemD recommendations as was stated in 2020, and that we will not change this just because of a few people having the request
[15:03] <teward> and then point at that spec
[15:04] <teward> rbasak: who has vote powers on that spec proposal btw since it's "pending review"
[15:04] <teward> (i'd like to put my opinion on heh)
[15:04] <teward> oh foundations
[15:04] <teward> i answered my own question
[15:04] <teward> *goes to obtain coffee*
[15:05] <rbasak> teward: no "vote powers". It's Ubuntu development so done by consensus, or escalated to the TB for a decision if that doesn't work :)
[15:05] <teward> so, opinions/questions should end up on the thread then. 
[15:05] <teward> i'll read it once i'm awake and see if i have anything i should voice in (a-la httpd)
[15:06] <teward> but i see you already did half my work for me (lighttpd etc.) in your last reply in April
[15:07] <rbasak> athos: there's also vorlon's opinion here: https://discourse.ubuntu.com/t/spec-definition-of-an-online-system/27838/4?u=rbasak
[15:07] <teward> but going back to the nginx bug, should I just reiterate that we're sticking to our decision and defining that network-online.target should *only* be used when it's needed?
[15:08] <teward> and that's a customization doable by sysadmins and not by default?
[15:08] <rbasak> That was the prior decision.
[15:08] <teward> unrelated: kerberoasting sucks and is a legit problem in AD environments >.<  *goes to secure a client's environment with insane firewall lockdowns*
[15:09] <rbasak> If server team people want to revisit that, then sure we can look at it again, but any conclusion should cover all the points raised in that Discourse thread and the other bugs.
[15:10] <teward> then, should this even be loaded as a discussion thread via server team email, or should we just stick to the decision we made?  I don't see a reason esp. with that spec in mind now to change our decision, and I'm happy to reiterate it
[15:12] <rbasak> I don't expect the decision to change, but will see what my colleagues think when it's raised.
[15:12] <teward> ACK
[15:12] <teward> if the decision is "we'll leave it the same as it currently is" then i'll happily reply i have a reply ready to go :p
[15:12] <teward> and i should stab debian-devel and see if they have a spec/definition for network-online.target and what defines "network online" :P
[15:12] <teward> (because curiosity)
[15:24] <teward> rbasak: i assume you guys have a meeting where you discuss this, or is this going to be an ubuntu-server@lists.u.c thread that I can chime in on?
[15:24] <teward> (though you already know my opinion)
[15:27] <teward> so if you or athos want to be my voice in your discussion feel free :)
[15:27] <teward> now if only the lists didn't get shoved into my junk mail >.>
[15:28] <rbasak> teward: we have an internal daily meeting, but if there's actually somehting to discuss we can do it on the ML or here.
[15:29] <teward> ack just let me know how it goes, i don't think there's going to be any objection to keeping status quo for nginx :P
[15:29] <teward> just keep me in the loop if possible :)
[15:29] <rbasak> Yep
[15:29] <teward> pretty sure the decision from 2020 will stand given the current state of that spec too
[15:29] <teward> and vorlon even stating directly that netowrk-online.target should be very limited in use
[15:30] <teward> and your discussion of httpd stuff (case in point: a friend of mine uses a local Apache2 and phpmyadmin on an airgapped (aka "no internet") dev server so network-online.target would not be desired there heh
[15:32] <athos> I will gather all the urls and points here and start the discussion in the ML. It seems there won't even have a discussion at all, but at least we will have a reference for the issue in the future :)
[16:31] <athos> teward: nobody seems inclined to hop into the discussion to change the current behavior we have across the distro. So, on a second thought, I don't even think we need a ML thread for that (given the discourse discussion already exists). You said you have a reply ready for that bug, is this right? do you want to go ahead and push the button? :)
[16:35] <jedininjarob> hey how small is a server install, smaller then Alpine? 
[16:35] <teward> yeah i'll push the button and reply that the Server Team upholds the original decision circa-2020
[16:35] <teward> athos: ^
[16:36] <teward> i may not be part of the Canonical server team but I'm still around so :P
[16:37] <jedininjarob> imlooking to build a slim system and have tiling widow manager, for an AI build work stastion, looking for opions
[16:37] <ogra> jedininjarob, you cant really compare the two ... one is a server installation for actual machines, the other is a cloud container OS ...
[16:38] <jedininjarob> really ok,
[16:38] <ogra> jedininjarob, if you want to compare something you'd better compare alpine to the ubuntu cloud images 
[16:39] <jedininjarob> nah,lol  any sudjestion then on a bare min system would a server do it?
[16:39] <jedininjarob> alpine on baremetal dumb idea them?
[16:41] <teward> athos: done.
[16:44] <jedininjarob> did i just get kicked?
[16:44] <patdk-lap> by yourself? yes, yes you did
[16:44] <jedininjarob> lol
[16:44] <patdk-lap> jedininjarob has quit (Remote host closed the connection)
[16:44] <jedininjarob> dang me
[16:46] <jedininjarob> howslim is a server install "ill put it on a laptop" to run AI stuff and tiling window manager, bad use case?
[16:46] <patdk-lap> I always install jeos/minimal for servers
[16:46] <patdk-lap> those are under a gig of diskspace
[16:46] <patdk-lap> but it removed a lot of things people normally expect
[16:46] <patdk-lap> server installs dont have window managers
[16:47] <patdk-lap> those are called desktops :)
[16:47] <jedininjarob> i need realy access to python,internet forupdate "wifi" drivers and tilingmanager othertoolsetc..
[16:47] <jedininjarob> :)
[16:58] <athos> thanks, teward!!!
[18:12] <jedininjarob> that isnt nessicarily the exactdefininstion of a markov decision processing,, markov chains are just numbered sequences USED ina certain way,  but specificaly your talkingabout input processing i think your asking is indeed validbut misguided in inplementastion....
[18:12] <jedininjarob> markov chains need a specific implementastion befor they are MARKOV chains other wise...itsjust stringsofniumbers with somemaths