[07:35] <lordievader> Good morning
[11:02] <catphish> i'd like to configure an ethernet interface with a /32 primary IP and /24 secondary IP, will ifupdown let me do this?
[11:03] <catphish> or am i better off configuring the /24, then adding the /32 and updating the source IP for routes afterwards?
[11:04] <lordievader> Believe so. IIRC you can simply add two "address" specifications.
[11:05] <catphish> i didn't know what was even possible! i've always used post-up commands for secondary IPs  in the past
[11:05] <catphish> alternatively i guess i can just add the /24 with ifupdown normally then add the /32 as an extra IP, and default route with the custom source IP in a post-up
[11:06] <catphish> the aim is to have a /24 LAN IP, but then a /32 IP for outbound WAN traffic
[11:08] <catphish> which IP is primary is probably irrelivant to the source on the defaut route anyway
[11:08] <catphish> thanks, i'll have a play
[11:20] <catphish> turns out i'm an idiot, these servers have netplan
[11:21] <catphish> so i just need to work out how to choose the source IP for the default route in netplan
[15:18] <coreycb> sahid: python-tabulate (git)merged and uploaded to focal. thanks for the updates.
[15:19] <tomreyn> so... 2.5 months to go for autoinstall to be implemnted, tested, serious bugs to be fixed. is this actually realistic?
[15:20] <tomreyn> 18.04 LTS's server installer was a mess, I have a feeling it'll be the same in 20.04 :-/
[15:22] <sahid> coreycb: ack, thanks for the review
[15:23] <sdeziel> tomreyn: someone's working on this ATM, see https://discourse.ubuntu.com/t/server-autoinstall-design-questions/14207
[15:24] <tomreyn> sdeziel: yes, and my calendar says january 31st
[15:24] <tomreyn> i'm glad it's being worked on, though
[15:30] <tomreyn> there once used to be a principle (or just a goal?) to get major changes into the release before an LTS, and this semed to make a lot of sense.
[15:31] <tomreyn> anyways, this is the wrong place to spread a bad mood, i'm just disappointed with where ubuntu is heading. will move it elsewhere.
[15:51] <rbasak> tomreyn: let's wait for the outcome. The installer is a little special here - it can now be updated out of band of Ubuntu releases. Not being directly involved with it I'm not sure what the plans are around that, but it does mean that the usual risk is reduced. The usual hard deadline is feature freeze anyway, and we're not there yet.
[15:56] <tomreyn> I can't live update the installer on airgapped systems (yes, can be a corner case). I'll not be able to wait, but will certainly watch.
[16:38] <isostatic> I'm reserving judgement tomreyn, but in theory if the installer didn't work until August, a working server CD / etc with 2004 could be released then
[16:47] <tomreyn> isostatic: sure, if it'll be ready then, but ideally in april.
[17:33] <rbasak> isostatic: but wouldn't you want the ISO to remain...static? :-P
[17:34] <isostatic> My build ISO hasn't changed since 2008, other than a new initrd and kernel and menu item every 2 years :D
[17:34] <isostatic> (Actually I lie, I did update isolinux to use a pretty menu about 4 years ago)
[18:41] <sahid> coreycb: cinder for focal in ready in my repo
[18:54] <johnfg> hi folks
[18:56] <johnfg> The installation of 19.10 server, LAMP pkg, installed mysql vs. mariadb.  Is mysql what's 'expected' on ubuntu vs. mariadb?
[18:59] <quadrathoch2> mariadb is the expected LAMP stack johnfg
[18:59] <sarnold> johnfg: that's your choice; mysql is in main, so there's more testing around it, but the mariadb updates provided by a community member are usually pretty timely
[18:59] <johnfg> quadrathoch2: Coming from debian buster, I thought so too.  However, mysql is installed and not mariadb.
[19:00] <quadrathoch2> johnfg: welp what sarnold said, I didn't even know :) so here you go
[19:05] <johnfg> I guess since it's here installed, unless I have problems, I'll stick with mysql.
[19:13] <johnfg> Truly, I've not found very much, if any, difference between the 2, in executing anything.
[19:16] <sarnold> johnfg: just be sure you don't try to swap between the two just for fun :)
[19:17] <sarnold> something like 80% of the bugs I see on both in launchpad come from folks who have tried swapping between them on the fly, or try one and then the other
[19:20] <sdeziel> IIRC, only mysql has an Apparmor profile shipped by the package
[19:20] <sdeziel> I remember the mariadb maintainer trying to get one too but I don't think it happened yet
[19:20] <sarnold> yeah, having a profile in one but not the other is like 60% of those bugs
[19:22] <johnfg> Good advice!  Thanks!
[19:23] <sarnold> (otto's even been working on upstream apparmor project to try to improve the notifications around apparmor denials :)
[19:23] <johnfg> I just noticed, working on the same thing, that in ubuntu, as it was on debian, root is the owner.group of /var/www.  On debian, I changed everything to www-data.www-data.  Should this be on ubuntu-server as well?
[19:24] <sdeziel> sarnold: I guess you were right about wireguard ending up in 20.04 kernel: https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-20.04-Adds-WireGuard
[19:27] <sarnold> johnfg: I think the webserver process should only have write access to log files and database sockets; maybe an upload directory if it runs an application that lets users upload..
[19:27] <sarnold> yay :)
[19:46] <johnfg> typo3 9.5.13 won't work with mysql, but will with mariadb.  If I want to stick with mysql, I'll have to wait for the point version of typo3-cms-10 to come out in the spring.
[21:52] <orentanay> I have a local ubuntu apache2 server for testing websites, but i'm having a very hard time getting self signing ssl to work. Can someone look at my config files and see if i'm doing something wrong? https://pastebin.com/DPZMJkBN  thanks.
[21:54] <sarnold> orentanay: fix the connection error before working on tls
[21:55] <sdeziel> orentanay: have you installed PHP 7.1 from a PPA by any chance? 18.04 ships with 7.2
[21:55] <orentanay> yes, I installed 7.1
[21:55] <sdeziel> why?
[21:55] <orentanay> this works just fine in http without the redirect
[21:56] <orentanay> b/c I'll need to work with Magento 2.2, and it's only 7.1 compatible
[21:56] <sdeziel> ah OK
[21:56] <sdeziel> orentanay: pastebin the output of "apache2ctl -S"
[21:57] <orentanay> it wasnt my call, but we migrated just before Magento announced they were discontining support for 2.2, and now we have to migrate to 2.3. not a great day.
[21:57] <orentanay> ok, one sec.
[21:59] <orentanay> wow, that was interesting...
[21:59] <orentanay> AH00526: Syntax error on line 48 of /etc/apache2/sites-enabled/mysite-ssl.test.conf:
[21:59] <orentanay> SSLCertificateKeyFile: file '/etc/ssl/private/mysite.test-selfsigned.key' does not exist or is empty
[21:59] <orentanay> Action '-S' failed.
[21:59] <orentanay> The Apache error log may have more information.
[21:59] <orentanay> I may have misplaced a file?
[22:01] <tomreyn> does the SSLCertificateKeyFile exist then?
[22:01] <orentanay> checking...
[22:02] <orentanay> yes, it's there, and it's not empty
[22:03] <orentanay> right next to ssl-cert-snakeoil.key
[22:04] <tomreyn> and if you run    file    against it it says?
[22:05] <orentanay> cannot open, permission denied. I see that the user:group for snakeoil is root:ssl-cert and for my key its root:root
[22:06] <orentanay> could it be as simple as the wrong group?
[22:06] <tomreyn> apache httpd on ubuntu normally starts up as root so it can read those files, spawns child processes which drop privileges (IIRC)
[22:06] <tomreyn> so unless it's not got the read bit set (chmod-wise) i *think* it should be readable to root
[22:07] <tomreyn> so when you    sudo file   it, it says?
[22:08] <orentanay> ASCII text
[22:08] <orentanay> the snakeoil file has permissions -rw-r----- and my file has -rw-------
[22:09] <tomreyn> hmm, and if you     sudo head -1 /etc/ssl/private/mysite.test-selfsigned.key | hd     does it return readable text?
[22:09] <orentanay> yes
[22:10] <tomreyn> also run file and head -1 against the snakeoil key and compare
[22:10] <sdeziel> sudo openssl rsa -in /etc/ssl/private/mysite.test-selfsigned.key -noout; echo $?
[22:11] <sdeziel> should return 0 unless you use something fancy like ECDSA
[22:11] <orentanay> tomreyn, identical output.
[22:11] <tomreyn> sdeziel's approach is better.
[22:12] <orentanay> it returned 0
[22:12] <sdeziel> orentanay: next op is comparing this: openssl rsa -in /etc/ssl/private/mysite.test-selfsigned.key -noout -modulus | md5sum
[22:13] <sdeziel> orentanay: with openssl x509 -in /etc/ssl/certs/mysite.test-selfsigned.crt -noout -modulus | md5sum
[22:13] <tomreyn> i also like inspecting -text
[22:13] <sdeziel> orentanay: invoke those oenssl commands with sudo
[22:14] <sdeziel> tomreyn: agreed for the x509 one
[22:14] <tomreyn> right
[22:14] <orentanay> trying it now.
[22:17] <orentanay> they output is identical
[22:18] <sdeziel> orentanay: what happens if you use the snakeoil cert and key instead?
[22:18] <orentanay> I haven't tried that, yet
[22:24] <orentanay> just tried it, and I got the same result
[22:25] <orentanay> I made sure to restart apache before testing
[22:25] <sdeziel> orentanay: apachectl -S still complain even for the snakeoil key?
[22:26] <orentanay> yes
[22:26] <orentanay> AH00526: Syntax error on line 50 of /etc/apache2/sites-enabled/idwholesaler-ssl.test.conf:
[22:26] <orentanay> SSLCertificateKeyFile: file '/etc/ssl/private/ssl-cert-snakeoil.key' does not exist or is empty
[22:26] <orentanay> Action '-S' failed.
[22:26] <orentanay> The Apache error log may have more information.
[22:27] <sdeziel> orentanay: what do you have from "ll /etc/ssl/"
[22:28] <sdeziel> orentanay: oh, "sudo apachectl -S"
[22:30] <orentanay> that outputs quite a few lines, but it seems the first 2 are most relevant...
[22:30] <tomreyn> oops :)
[22:31] <orentanay> *:443                  mysite.test (/etc/apache2/sites-enabled/mysite-ssl.test.conf:38)
[22:31] <orentanay> *:80                   is a NameVirtualHost
[22:31] <sdeziel> yeah, facepalm
[22:32] <tomreyn> i failed there, too
[22:32] <sdeziel> orentanay: now, are you able to start/restart apache2? If yes, please show "ss -nlt"
[22:33] <orentanay> restarted apache, and here is the output...
[22:33] <orentanay> State                   Recv-Q                    Send-Q                                        Local Address:Port                                       Peer Address:Port
[22:33] <orentanay> LISTEN                  0                         80                                                127.0.0.1:3306                                            0.0.0.0:*
[22:33] <orentanay> LISTEN                  0                         128                                           127.0.0.53%lo:53                                              0.0.0.0:*
[22:33] <orentanay> LISTEN                  0                         128                                                 0.0.0.0:22                                              0.0.0.0:*
[22:33] <orentanay> LISTEN                  0                         128                                                       *:443                                                   *:*
[22:33] <orentanay> LISTEN                  0                         128                                                       *:80                                                    *:*
[22:33] <orentanay> LISTEN                  0                         128                                                    [::]:22                                                 [::]:*
[22:34] <orentanay> sorry, i should have used patebin for that one
[22:35] <sdeziel> orentanay: looks good to me
[22:36] <orentanay> BTW: I really appreciate all the help thats been offered.
[22:43] <tomreyn> orentanay: so this is Ubuntu 18.04 LTS, fully updated, with apache httpd 2.4.29 from Ubuntu, PHP 7.1 from Ondřej Surý's PPA, and you've not changed how apache httpd starts and which user it runs as etc?
[22:45] <tomreyn> oh and does ssl work fine now, or is this not yet fixed?
[22:47] <orentanay> still no ssl, but correct on everything else you mentioned.
[22:48] <tomreyn> orentanay: so are there still errors on the log? still the same error - i assume not?
[22:50] <orentanay> looking for the log files now...
[22:52] <tomreyn> also ( if you're ok with posting this to https://termbin.com ):    sudo lsof -n -sTCP:LISTEN -iTCP:80 -iTCP:443 | nc termbin.com 9999
[22:54] <orentanay> onesec...
[22:56] <orentanay> Here you go https://termbin.com/otnd
[22:57] <tomreyn> hmm no ipv4, but ss -nlt showed ipv4.
[22:58] <tomreyn> the rest looks fine though. so what about the logs?
[22:58] <tomreyn> i think it's unusual that the server would start up if there are still critical SSL key issues.
[22:59] <tomreyn> orentanay: so what does "still no ssl" look like?
[23:02] <orentanay> Here's a small section of my error.log https://pastebin.com/XyHfnLpK
[23:02] <orentanay> I still get the refued to connect webpage.
[23:06] <tomreyn> so stapling will likely not work with a self-signed certificate (i haven't actually tried this, but it seems logical to fail)
[23:07] <tomreyn> so either comment out / remove this directive off your :443 virtualhost configuration or use a lets encrypt certificate
[23:08] <tomreyn> or a commercial certificate if you have one which can be used for this purpose
[23:10] <orentanay> thanks, I think that will be my next attempt. thank you for all of your help and time.
[23:10] <tomreyn> your certificate SubjectAltName (SAN) or Common Name (CN) also doesn't seem to match the FQDNs provided in the :443 virtual host configuration.
[23:13] <tomreyn> you're welcome.