User1: User2 hi there
User2: evening ruben23
User1: User2 im so sorry i forgot to take note of teh substitute of apt-get install linux-headers-server in Ubuntu server 18.04 lts, what was that again if you dont mind, really sorry
User2: User1 linux-headers-generic
User1: ;-) Thanks a lotr
User2: you're welcome :)
User3: Good morning
User3: adol-christin: What kind of domain are you referring to? DNS domain, AD domain?
User3: What is the actual problem?
User3: !paste
User4: For posting multi-line texts into the channel, please use https://paste.ubuntu.com | To post !screenshots use https://imgur.com/ !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
User3: Brr, you don't want to do that.
User3: 91.69.162.6 is a representation for the entire network.
User3: That said, since you are setting up DNS you don't want to be editing your hosts file since it defeats the purpose.
User3: Youtube is rarely good for these kind of things.
User3: You rather want to read manual pages, rfc's or tutorials of known good sources.
User3: You first want to fix your DNS setup, currently I get an NXDOMAIN on www.aetherdreams.com.
User3: Then once www.a.c points to the IP address of the server you can tell Apache that its servername www.aetherdreams.com
User3: Yes
User3: The description reads 'glue records', this is not what you want. You want to change the regular records.
User5: adol-christin: you need to stop messing around with public DNS and public servers until you know what you're doing.
User3: +1 to that, first figure out how things work before diving in.
User3: I.e. read documentation
User3: Perhaps even RFCs to figure things out.
User5: adol-christin: no, you don't know what you're doing. please stop messing with  public infrastructure, you'll cause damage to someone.
User5: Set up a VM and do it all on your VM, in your LAN, learn all the things and concepts first.
User6: adol-christin: setting up servers needs basic knowledge, you cant just random do things
User5: adol-christin: becase in 20+ years of my experience I've seen it many times. noob setups getting pwned by bots and starting ddos attacks and other illicit things. open email relays. open dns resolvers....
User6: adol-christin: did you read the server manuals we gave you last night?
User5: Set up a VM and learn things in that first. Folks here will be delighted to help with specific questions about that (after you've read required docs and tried yourself first).
User6: !server | start here
User4: start here: Ubuntu Server Edition is a release of Ubuntu designed especially for server environments, including a server specific !kernel and no !GUI. The install CD contains many server applications. Current !LTS version is !Bionic (Bionic Beaver 18.04) - More info: http://www.ubuntu.com/products/whatisubuntu/serveredition - Guide: https://help.ubuntu.com/lts/serverguide - Support in #ubuntu-server
User6: adol-christin: before going to production, try the VM advice blackflow provided
User5: in addition to this, Digital Ocean has plenty of useful How-To articles on server applications and configurations. Google is your best friend there.
User5: for example, like this:  https://www.google.com/search?client=ubuntu&channel=fs&q=how+to+set+up+apache+site%3Adigitalocean.com
User3: Of what?
User3: That doesn't really matter.
User6: 'they'?
User5: User3 it might if there's no GPU which was suggested yesterday as cause of crashes.
User3: The point is, that you need to learn things (read, try out in isolation, etc) first before putting things into production.
User5: Sure, if you have specific questions, pertaining to Ubuntu, we're all ears here.
User3: Like blackflow said, if you put in the effort we are willing to answer questions, sure.
User6: adol-christin: ubuntu server is also a responsible task, at some point you will need to be on your own too
User5: and you'll need to know how to fix things over ssh only. running rescue environments, mounting your main installation's disks to fix broken boots, that's also important experience for running remote servers.
User5: who's "they" btw? which hosting company are you renting that behemoth server from?
User7: Hello, seeing very strange apache2 behavior on bionic (2.4.29-1ubuntu4.7) with latest updates (regression fix for openssl1.1.1)
User7: apache freshly restarted -> do a run of ssllabs.com/ssltest against it and 2 apache2 processes stuck at 100% apparently indefinitely
User7: User8 https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1836329 -> regression in 4.6 -> 4.7 in LTS :(
User4: Launchpad bug 1836329 in apache2 (Ubuntu) "Regression running ssllabs.com/ssltest causes 2 apache process to eat up 100% cpu, easy DoS" [Undecided,New]
User8: User7 Why me?
User7: User8 bad fingers on my side (was unintended), sry
User8: No worries.
User1: hi there guys where do i configure the my.cnf when i used MariaDB10.2 its quite different now from MariaDb5.5
User1: any idea guys.?
User9: Without gasoline and a match how would you diagnose a port flap using DAC's in bond to mlagged switches. It starts happening after 8 days after a reboot... I've changed firmware on cards, installed driver as dkms as manufacture says, changed kernels, changed DAC cable manufactures.
User9: It's randomly after 8 days happening on 4 servers. These 4 servers are some older supermicro's. I wouldn't think it would be the motherboard or pcie slot issue. The flap is only on one of the DAC's, the other interface seem stable but it's on a different switch.
User9: I'm thinking next step is to create more mlagged interfaces and move the servers into the new port channels to see if it's the first 4 ports of this switch.
User9: If that doesn't solve it should I change OS or nic cards next?
User10: maybe increase log verbosity on the module (if available), see if there are power saving options there you can disable
User9: Your talking about nic power settings and not server governers?
User10: User9 yes, but i really have 0 experience with DAC, should have said so.
User10: switching governors might also be worth a try, sure.
User9: I use them quite a lot and I have the same cards in others servers using the same network config and they are working.
User9: There are power settings on the mellanox cards.
User9: I'm not even sure if the server or the switch side that's dropping
User9: The switches are arista and since I didn't buy them new I have no support from them.
User10: aaw crap. they can do good enough logging though. or port mirroring.
User10: at least the non entry models
User9: They are DCS 7150  so not entry level.
User9: ceph is pretty resiliant as long as the server goes offline, it doesn't like the bouncing ethernets.
User9: I think there is a timeout command that I can set on the bouncing on the switch. That way once it starts it will hold the port offline till the timer clears.
User10: maybe you can do flap detection and fencing near the source instead.
User10: actually your approach may be better
User9: Well I think that is how it works...
User9: Here is a paste of the logs https://pastebin.com/s13dDb68
User11: anyone with an 18.04 machine successfully configured a Bridge on their system with Netplan that lets the system itself have Internet and be reachable, but also allow cintainers such as LXD containers to use the bridge to get DHCP addresses too?
User12: User11 I think so, let me check if I have something to share
User12: User11 correction, I'm using a different bridge for the host and separated bridges for my lxd containers. That may still be useful to look at for you though https://paste.ubuntu.com/p/M6wwcMXTkR/
User11: User12 thanks.  running into some headaches with macvlan on LXD by default.  The headache I have is that it's being derp with the containers behind
User11: maybe because VMware's involved it's eating packets...
User11: might mess with it later right now I just need to get this damn mail server set up >.<  *uses straight NAT for reasons in the interim*
User12: User11 macvlan is annoying to deal with
User11: yes, it is
User11: so is VMware promiscuous mode eating packets from the host
User12: because the host needs also a macvlan device if you want it to talk with your containers?
User12: s/\?$//
User11: i don't need host -> container I just need Network <--> Container
User11: and container is making DHCP requests
User11: but they're not getting to the virtual firewall;
User11: so IDK what's up there
 * teward will mess with that later
User12: User11 with macvlan, your containers will show up with a new MAC when they get to VMWare so maybe you need to allow this virtual NIC to have more than 1 MAC
User11: not sure that's doable, but promiscuous mode and accept mac changes is enabled
User11: but VMware's having a hell of a time with it
User11: so IDK
User11: i'll mess with that in a separate VM later for testing
User11: FOR NOW
User11: I'm just going to straight NAT the container ports to the host
User11: and vice versa
User13: Ok, this is weird. Brand new 18.04 LXC container, from the download template. If I try to start salt-minion, ssh, or postfix, they say "Job for salt-minion.service canceled."
User11: User13 did you check syslog or other logging mechanisms to see why it explodified?  :p
User13: teward, still hunting. I rebooted it, and now "systemctl start salt-minion" returns "Failed to connect to bus: No such file or directory"
User13: As does 'status' so it's not salt-specific
User11: well salt I think there's known problems with
User11: but i was more curious about ssh and postfix
User13: teward, ssh does the same
User13: Also FYI this is the repo.saltstack.com salt
User13: And I did have a problem earlier where one of my salt states tried to set the timezone, which apparently doesn't work in containers
User13: Because timedatectl doesn't work
User13: I'll rebuild the container.
User2: that sounds like super-unhappy dbus
User11: ^
User11: User2 but wouldn't that have a global effect rather than a container-specific problem?
User11: or is it possible there's apparmor isolation going on?
User2: rebuilding the container will be a pretty good indicator, I hope
User13: I have this exact container setup running elsewhere, so it has to be something changed recently
User13: ok, I made the container again, ssh was running. Installed salt-minion, accepted key, rebooted
User13: ssh and salt-minion came up
User2: yay! but .. bummer to not Know what the problem was
User13: Well, I'm not done applying the states yet.
User13: Doing them in parts this time
User13: I have a suspicion that linux-generic-hwe-18.04 getting installed in the container is what borked it
User2: hmm. any chance you've got a working container, can install that, and break your container?
User13: The kernel package was installed by Salt after container init, so I'm trying now with that package commented
User2: aha
User13: Previously all ceph clients were physical, so I forgot that it would install hwe
User13: ahah, no, that didn't fix it. But commenting out an entry I put in /etc/fstab did
User13: So I bet it's an apparmor profile issue
User13: But I did it in an identical container earlier!
User13: Ok, I got it to work by setting lxc.mount.entry properly and leaving /etc/fstab empty
ubuntu-server
Ubuntu IRC