[00:03] <seekr> teward: (I don't know whether this inquiry is out of scope for this channel; I trust someone will tell me if it is.) I've just moved a site to a new server, and think I'm having a problem with mod_rewrite.  I followed the instructions in an article at https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_rewrite as to "a2enmod rewrite" and "service apache2 restart" (on an Ubuntu server).  The module was not previously activated,
[00:03] <seekr> judging by the absence of a message to that effect being produced.  However, I'm finding that accesses that used to work (on the previous server) are now failing.  :(
[00:13] <seekr> I've grown very tired and must now go into nap mode for a while.  |-)  But if anyone has any possible answers, please do let me know
[00:35] <cryptodan_mobile> seekr: I would check the error logs. Something might be used that's depreciated in the new server
=== jelly-home is now known as jelly
[01:47] <seekr> cryptodan_mobile: I was thinking similar thoughts whilst drifting off into sleep mode, from which I've just emerged.  Will investigate.  Thanks.
[01:54] <seekr> cryptodan_mobile: It was a good idea, but I see nothing in error.log corresponding to such a problem.  The access.log file shows only 404s for attempts to access the root-level pages.
[01:54] <seekr> Joomla! is supposed to redirect such accesses, I think.
[01:56] <seekr> I suspect mod_rewrite isn't fully active, and will thus resume my search for advice on enabling it in Apache.
[02:01] <seekr> There must be a way to do a simple test, which I will now seek.
[10:57] <seekr> tomreyn: Good morning.  Anybody home?  :)
[10:59] <tomreyn> seekr: hi, i'm around.
[11:02] <seekr> great - I have some questions about mod_rewrite in Apache.  Do you have knowledge/experience in that area?
[11:02] <seekr> I got some info on #httpd last night, but I'm having trouble sorting through it.  I'm looking for a quick-ish way to diagnose and fix my problem,
[11:03] <seekr> which is that Apache appears to not be doing URL rewriting for the Joomla! CMS.
[11:04] <tomreyn> generally, please just ask your questions right away, most folks over here are quite pragmatic and prefer this over exchanging greetings (which causes back and forth).
[11:04] <tomreyn> this said, thanks for the kind greeting ;)
[11:04] <seekr> tomreyn: Well, I just stated my question in a generic sort of way - it's the most specific I can be at this point, I think.
[11:04] <seekr> yw
[11:06] <seekr> tomreyn: I have several menu items on all pages in a navigation area, which use URLs that refer to pages at the root of the site (e.g. /meetings) - but I'm getting 404 errors in the Apache log for those links.
[11:06] <seekr> Apache should intercept those URLs and replace them with what's needed to load the appropriate pages.
[11:06] <tomreyn> you're asking about apache httpd. apache is a project incubator, an umbrella for many projects. the webserver just happens to be the most known one, but it's good to specify "httpd" (you did by mentioning the channel name)
[11:07] <seekr> right
[11:07] <seekr> I mean the Apache server.  :)
[11:07] <tomreyn> the rewrite module comes with its own logging engine. by default, it doesn't log.
[11:08] <tomreyn> consider enable logging for the rewrite engine, so you'll know whether it's working and what it does / how it handled requests.
[11:08] <seekr> I did see something in one of the articles about setting a logging level, but I'm not sure where to put the directive - apache2.conf?
[11:09] <seekr> tomreyn: I'm looking at https://httpd.apache.org/docs/current/mod/mod_rewrite.html
[11:10] <tomreyn> you can either put this in the module configuration file, those are in /etc/apache/mods-available/
[11:10] <seekr> It gives the example:  LogLevel alert rewrite:trace3
[11:10] <tomreyn> in this case it should be rewrite.conf
[11:10] <tomreyn> this will then apply server-wide
[11:11] <tomreyn> or you can do it in the virtuaolhost configuration file, which should be located in /etc/apache2/sites-available/
[11:11] <seekr> Well, I see only symlinks in mods-enabled
[11:11] <tomreyn> i didn't write "mods-enabled"
[11:11] <seekr> tomreyn: can it be done in the .htaccess file for the site?
[11:11] <seekr> yes, I know - you wrote "nods-available."
[11:12] <tomreyn> i wrote "/etc/apache/mods-available/", which is wrong, it should have been "/etc/apache2/mods-available/"
[11:14] <seekr> right
[11:14] <seekr> Are all the *.conf files in that directory processed when the server begins operation?
[11:15] <tomreyn> https://httpd.apache.org/docs/current/mod/mod_rewrite.html is the right documentation indeed. as with all apache configuration directives, the directives listed there always say which context they can be used in. for example, the "RewriteCond Directive" can be used in the server config, virtual host, directory and .htaccess contexts
[11:15] <tomreyn> this should answer <seekr> tomreyn: can it be done in the .htaccess file for the site?
[11:15] <seekr> gotcha
[11:16] <tomreyn> yes, and when it is reloaded <seekr> Are all the *.conf files in that directory processed when the server begins operation?
[11:17] <seekr> I guess I'd assumed that the files in mods-enabled get moved from mods-available when specific modules are selected for use - but my assumption may be incorrect.
[11:17] <tomreyn> .htaccess files are special in this sense since they have to be loaded and parsed every single time a file or location in the same directory or below of them is accessed
[11:17] <tomreyn> ... so they cause considerable load, which you should try to prevent.
[11:18] <seekr> .htaccess, though less efficient, perhaps, is probably cleaner, in that it's site specific.  I've not yet figured out how to run multiple sites -- that's one of my next tasks after I get mod_rewrite working.
[11:18] <tomreyn> please read https://help.ubuntu.com/lts/serverguide/httpd.html to get a general understanding of how ubuntu uses the apache httpd <seekr> I guess I'd assumed that the files in mods-enabled get moved from mods-available when specific modules are selected for use - but my assumption may be incorrect.
[11:18] <seekr> will do - thanks
[11:20] <seekr> tomreyn: Does the load come from the server having to load the module each time it's working on the site whose .htaccess contains that directive?
[11:20] <tomreyn> .htaccess files are directory specific, plus have this property of being changeable during operation of the webserver (no reload needed). only if you depend on this property you should actually use the,. otherwise use the same directives in a <directory></directory> scope of the virtualhost configuration file. <seekr> .htaccess, though less efficient, perhaps, is probably cleaner, in that it's site specific.  I've not yet figured out how
[11:20] <tomreyn> to run multiple sites -- that's one of my next tasks after I get mod_rewrite working.
[11:21] <tomreyn> virtual hosts (multiple sites) should go to /etc/apache2/sites-available - read https://help.ubuntu.com/lts/serverguide/httpd.html for a better understanding of the mechanisms involved in this.
[11:22] <tomreyn> yes <seekr> tomreyn: Does the load come from the server having to load the module each time it's working on the site whose .htaccess contains that directive?
[11:22] <seekr> tomreyn: I was thinking of the other directives - to show debugging info - that one should be site-specific, not the one that refers to loading mod_rewrite - but if it gets loaded when the server starts due to the symlink we were talking about, there's no need to put the directive to load the module into .htaccess
[11:23] <seekr> (or into apache2, which you already told me is unnecessary)
[11:23] <seekr> *apache2.conf
[11:23] <tomreyn> it's not a huge amount of load if you've only got a few visitors, but you should always try to set your systems up with the most performance, as long as it doesn't mean you're disabling required features or adding a lot of complexity.
[11:24] <seekr> agreed - sounds completely reasonable
[11:26] <tomreyn> by site-specific, do you mean in the virtualhost scope or spache 2 httpd scope (the highest/greatest)?
[11:26] <seekr> tomreyn: I just realised that I'm still thinking like I'm in a shared hosting environment.  I suppose that a fair bit of what's in the .htaccess that comes with Joomla! could get moved to Apache config files.
[11:27] <tomreyn> yes, this is usually so. web applications' documentation often describe configurations in a way that is suitable for shared hosting where there are many users whith ftp or sftp access to their every web space.
[11:28] <seekr> I mean that if I run several (web) sites, and I'm only trying to debug one of them, or to alter some property that applies only to a specific site, the appropriate directive should go into the .htaccess at the top level directory for some specific site.
[11:28] <tomreyn> if you don't do shared hosting (can still host multiple sites, just control is central with you) then it's better to move directives from htaccess files to a different context
[11:28] <seekr> yeah
[11:29] <tomreyn> ideally, your goal should be to be able to disable htaccess functionality entirely
[11:29] <tomreyn> you will not always be able to achive this goal but try to get as close as possible.
[11:30] <seekr> not a bad goal - as long as what's in those directives doesn't mess up operation of sites based on some other technology (e.g. Wordpress or plain HTML).
[11:30] <tomreyn> this will also help you identify overlapping directives
[11:33] <tomreyn> when you run a service, you aim for the most concise and condensed description of the service. you also try to remove dynamics, so that you can reliably tell how a service will behave at a given time based on the configuration you have. if you have .htaccess and shared hosting where users may change them files during apache httpd restarts, you can't really tell very well how things are behaving at a given time, since the user may have
[11:33] <tomreyn> changed consfigurations.
[11:34] <tomreyn> now think of the user being someone malicious who got write access to a shared webhost. if they can change htaccess files they can do more harm. so you don'T want them if you can get around it.
[11:36] <seekr> I guess that if (as I do in the VM server setting) I have complete control of the Apache server configuration, I can achieve what is now being done by means of .htaccess files within the sections of the config file that describes setting up the right environment for each specific site.
[11:38] <tomreyn> effectively you (almost) always want to have virtualhosts, even if you just have a website, it should go into a virtualhost configuration file in /etc/apache2/sites-available (with a symlink to that in sites-enabled)
[11:38] <seekr> I've become quite sensitive to security concerns, having recently gotten my sites on a shared hosting server locked due to one or more attacks, at least one of which added code to a whole lot of PHP files.
[11:39] <tomreyn> so you'd have a site specific virtualhost context. once you have this, you can just add a directory context into this virtualhost configuration and move the contents from a htaccess file there.
[11:40] <tomreyn> most of the time what causes your websites to be successfully attacked (they are generally under attack all the time, but most attacks dont succeed) is outdated webapps.
[11:40] <seekr> tomreyn: yeah - that's what I want to do - even though what I'm doing now is only intended to be temporary, it's a wonderful learning experience - I want to see how to set things up such that, as happens in a shared server setting, the URL used to access the server is used to direct control to files pertaining to some specific web site.
[11:40] <tomreyn> whole servers are usually successfully attacked due to insecure ssh passwords.
[11:41] <tomreyn> do you have your own doamin name and can fully manage dns for it?
[11:42] <seekr> Well, the one attack of which I became aware, which may not be the one producing what I was told by the server admin was producing attacks on other sites, was based on my attempt to configure a forum on my site.  As soon as I set it up, I began getting lots of subscription requests from what I assume to be a botnet, based in Poland.
[11:43] <seekr> I have several domains.  I can control one of them - I could move another of them - and a third one would require my making a request to the domain name owner.
[11:44] <tomreyn> that's normal. but not the cause. subscription requests, also successful subscriptions by spammers to a web forum should not yet allow them to make your server run requests against other web hosts on the internet.
[11:45] <tomreyn> if someone was able to make your server / shared host run requests against other internet hosts it means they gained some kind of (limited or full) code execution (at least php / whatever the web forum was based on)
[11:45] <seekr> That's what I'm hoping, because I'd like to run the latest version of the site, since my previous backup goes back six weeks.  I intend to disable to forum module, in any case.
[11:46] <tomreyn> seekr: if you have full control over a dsingle domain name, including the ability to create subdomains, that's good enough for testing virtual hosting.
[11:46] <seekr> tomreyn: The clamav output provided by the server administrator showed a ton of infected PHP files, and evidence that the attack that caused that corruption happened several years ago, when I was attempting to run a standalone forum system.
[11:47] <tomreyn> right, so years ago you were running indecure software or insecure configurations of a software there, allowing the site to get compromised
[11:47] <seekr> I had actually seen the strange code in lots of PHP files, but had assumed that it had gotten stuck there by the web hosting company for some commercial purpose.  In retrospect, I should have investigated as soon as I noticed that code a couple years ago!
[11:48] <tomreyn> back to domains. if you can create subdomain1.mydomain.com through subdomain2.mydomain.com and point them to your webserver, you'll have a good foundation to test virtualhosting.
[11:48] <seekr> tomreyn: I only ran that site for a year or so, but the damage was done - didn't matter that I was no longer running that site, since the infection was throughout my account.
[11:49] <seekr> yes - that's precisely what I intend to do
[11:49] <tomreyn> your web host should never touch anything you place in a shared host, unless it's for security reasons, but then then they'd tell you. it should be under your exclusive control.
[11:50] <seekr> So I want to both direct access based on what domain name is being used, if I decide to move one of the domains (which I won't do unless the old host turns out to be too much trouble to go back to), and the second is to set up subdomains, which I've only ever done previously by means of cPanel
[11:51] <tomreyn> (this said, they might inject ads when delivering content if they'Re a free webhost, but this should never mean they change your files.)
[11:51] <seekr> tomreyn: yeah - I should have immediately opened a trouble ticket - was too lazy - "live & learn!"  :-\
[11:52] <tomreyn> sure, we all make progress this way. ;)
[11:52] <seekr> slowly but surely  :)
[11:53] <seekr> "Experience is a hard teacher" (and the moon is a harsh mistress :) )
[11:54] <tomreyn> so what i'd do about learning how vhosts work is to create three directories, one for each (sub)domain / virtualhost: /var/www/site1 to /var/www/site3, and in these directories just place an index.html file saying "site1" to "site3".
[11:54] <tomreyn> and then you setup the virtualhosts for those documentroot's in /etc/apache2/sites-available
[11:55] <seekr> good idea - is apache2.conf the best place to put the virtual host directives?
[11:55] <tomreyn> then you a2ensite those. and finally you reload the apache2 (httpd) service
[11:55] <seekr> right
[11:55] <tomreyn> no, virtualhosts should not go to apache2.conf
[11:55] <seekr> I'm looking forward to playing with that stuff!
[11:56] <tomreyn> in fact you should try not to touch apache2.conf. unless you're changing something which is already in there.
[11:57] <seekr> Sorry - I guess what I meant is things like "<Directory /var/www/>" for each of the subdirs - or is there a cleaner method?
[11:57] <tomreyn> (but even then you may prefer to override what's in apache2.conf by a configuration in /etc/apache2/conf.d/)
[11:57] <tomreyn> "you setup the virtualhosts for those documentroot's in /etc/apache2/sites-available"
[11:58] <tomreyn> directory directives are probably virtualhost specific and should thus go into a virtualhost configuration file in /etc/apache2/sites-available
[11:58] <seekr> Ah - so the directive I just mentioned just sets the top-level file system path, and the subdirs for the sites are assumed to reside within that one (alongside the default "html" dir).
[12:00] <seekr> In fact, I guess there should be something somewhere that designates "html" as the presently one-and-only directory hosted by the server.
[12:00] <tomreyn> if you have a virtualhost with a documentroot of /var/www/mysubdomain then you may want to have a "<Directory /var/www/mysubdomain>" directive in there to apply directives to this / location of the site
[12:01] <seekr> But that stuff would go into the conf file in sites-available?
[12:01] <tomreyn> yes
[12:01] <seekr> okay - I'll poke around in that directory and see what I can find that looks interesting.  :)
[12:02] <seekr> I've been reading that Ubuntu httpd article, and am finding it quite interesting - thanks again!
[12:03] <tomreyn> here's a different take on ubuntu / debian style apache httpd configurations and virtual hosting: https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-ubuntu-16-04
[12:04] <seekr> BTW, I found an expert in the #httpd channel last night who seemed somewhat hostile to the Debian style organisation of files talked about in the Ubuntu article.  Seems they don't care to provide support for such systems.
[12:04] <tomreyn> i'm saying "ubuntu / debian style" since not all linux distros use this configuration file layout, others do it differently. the apache httpd project actually does it differently, too, and some of those folks don'T like the debian / ubuntu wqay at all.
[12:04] <seekr> Thanks much - yeah 16.04 is what I'm running, for reasons we talked about earlier.
[12:05] <seekr> tomreyn: yeah - that's what I experienced - seemed like a different tribe or religion  :)
[12:06] <tomreyn> thumbs is very annoyed by the constant stream of debian / ubuntu folks coming to #httpd expecting that the configuration file layout they see on their file system is 'the standard' and make false assumptions based on it.
[12:06] <tomreyn> which i can understand, and which is why i'm pointing this out.
[12:06] <tomreyn> this said, i do like the configuration layout debian + ubuntu use, and think it makes a lot fo sense for the most part.
[12:06] <seekr> yup - that's who I was talking to - he at least pointed me at a few articles, but refused to go into specifics - told me to go away and RTFM, in effect.  :)
[12:07] <tomreyn> yeah that's who you become when you're constantly confronted with people using the software you wrote in a way you didnt mean it to be used.
[12:08] <seekr> lol
[12:10] <tomreyn> it's actually a sad story. but it's nice that he's still helping out. there are other channels with many people in them where you never get a response at all.
[12:11] <tomreyn> #kvm is one of them
[12:12] <tomreyn> you may get a response but if you do it's by someone else seeking support there as well
[12:12] <seekr> KVM is the VM thing that some folks use rather than vbox?
[12:12] <tomreyn> yes, or the other way around
[12:13] <tomreyn> there are gazillions more kvm installations than there are vbox installations
[12:13] <seekr> depends on your perspective, I guess - there was some other thing that KVM required when I looked at it over a decade ago - maybe not really required.  Seemed harder to set up and use than vbox.
[12:13] <seekr> really!  hmmm
[12:14] <tomreyn> kvm is used by cloud hosts in huge numbers, vbox is used on some desktops
[12:15] <tomreyn> but they each have their uses in these environments.
[12:15] <seekr> tomreyn: I'm finding largely the same thing in the #joomla channel - the fellow who sysops the channel knows a lot and is friendly and helpful when he's around, which hasn't been all that much lately - there are somtimes devs there also, who chatter amongst themselves about arcane topics.
[12:15] <tomreyn> (but you can also use kvm on a desktop, which i do, and there may also be people using vbox on servers, it's technically possible)
[12:16] <seekr> ah - the Ubuntu server I'm using may itself be running in a kvm environment, then.
[12:17] <tomreyn> virt-what would tell
[12:17] <seekr> what's that?
[12:18] <tomreyn> a command and package providing this command which you can run on a linux shell to tell you which virtualization environment, if any, you're operating in.
[12:18] <seekr> oh - I'll take a look...
[12:18] <tomreyn> i guesses. it could guess wrong.
[12:18] <seekr> "bash: type: virt-what: not found"
[12:19] <tomreyn> *iT
[12:19] <tomreyn> weird error message
[12:19] <tomreyn> whic ubuntu is this?
[12:19] <seekr> I can install it, though.
[12:19] <seekr> 16.04 LTS
[12:20] <seekr> I used "type virt-what" to get that message.
[12:20] <tomreyn> oh, i didn't mean that you should type "type"
[12:20] <tomreyn> just "virt-what"
[12:21] <seekr> I know - I just like to look to see if unknown things are installed, rather than just trying to run 'em.  :)
[12:21] <tomreyn> maybe you should also install command-not-found
[12:21] <seekr> I installed and used the command, and it says "kvm" (!)
[12:21] <tomreyn> so you were right
[12:22] <seekr> yup - I am every once in a while  :)
[12:22] <seekr> "command-not-found - Suggest installation of packages in interactive bash sessions"
[12:22] <seekr> hmmm - I do generally get such messages, actually.
[12:23] <tomreyn> then it's probably already installed
[12:23] <tomreyn> it should be
[12:23] <seekr> "bash: type: command-not-found: not found"  :)
[12:23] <tomreyn> and the reason you didnt get the helpful hint on hoiw to install virt-what was just that you started the command with "type", which exists as a command
[12:24] <seekr> yeah - I did so intentionally
[12:25] <seekr> % command-not-found
[12:25] <seekr> command-not-found: command not found
[12:25] <tomreyn> dpkg -L command-not-found
[12:26] <seekr> https://termbin.com/nomv
[12:26] <tomreyn> ...lists the files installed from the given package, and their locations on the file system.
[12:27] <seekr> okay - I'll take a look - later - want to get back to my Apache config activities, ya know  :)
[12:29] <tomreyn> yeah, good luck there. i'll take a bit of a break.
[12:29] <seekr> okay - catch ya laters, then - thanks for all the help!
[12:43] <tomreyn> actually i'm still around, but so are others. just ask if you have more questions.
[12:52] <seekr> will do
[15:08] <TJ-> Anyone ever experimented/tested with dmdedup ?
[15:10] <tomreyn> maybe ask in #arch ;)
[15:14] <TJ-> hmmm, why, has that distro adopted it?
[15:15] <tomreyn> is there anything they have not adopted? :)
[15:16] <tomreyn> i guess they are more adventurous than the average ubuntu server maintainer
[15:17] <tomreyn> but i have no facts for you, just wasting time, sorry.
[15:17] <TJ-> I'm kinda scared of entering #arch :p
[15:18] <tomreyn> you'll be greeted by dust fairies whispering RTFM in a grumpy sysadmin voice to your ears.
[17:45] <hadifarnoud> I'm struggling to setup my floating IP in ubuntu 16.6
[17:45] <hadifarnoud> this is my config: https://gist.github.com/hadifarnoud/2ca1bc8f4f2723fd1eee0c2601058875
[17:45] <hadifarnoud> cannot ping my IP nor can I see it in ifconfig
[17:47] <hadifarnoud> can anyone help, I'm lost. no idea what went wrong
[17:56] <tomreyn> hadifarnoud: chances are the network interface name differs from eth0
[17:57] <hadifarnoud> tomreyn: it does show up in `ip a` but still no ping
[17:57] <hadifarnoud> it's frustrating
[17:57] <tomreyn> ok, well i'm not really into cloud init
[17:57] <tomreyn> also there's no "ubuntu 16.6"
[17:59] <tomreyn> 78.47.223.238 does respond to ping for me.
[17:59] <tomreyn> 138.201.116.62 also
[18:00] <tomreyn> no luck on 2a01:4f8:1c17:5d80::
[18:01] <tomreyn> hadifarnoud: ^
[18:01] <hadifarnoud> it says inet6 2a01:4f8:1c17:5d80::/64 scope global deprecated
[18:01] <hadifarnoud> in IPv6 I know nothing. no idea if I did it right
[18:03] <tomreyn> well the gateway is wrong
[18:07] <tomreyn> actually it can be right, ignore me
[18:09] <hadifarnoud> is it ok that it says scope global depricated?
[18:09] <hadifarnoud> `ip a` says that
[18:21] <TJ-> hadifarnoud: you've got an illegal IPv6 address there
[18:22] <TJ-> hadifarnoud: the interface identifier set to all zeros is reserved for subnet-router anycast
[18:22] <hadifarnoud> TJ- can you help me set correct one?
[18:23] <hadifarnoud> is this one correct? address 2a01:4f8:1c17:5d80:78:47:223:238
[18:23] <TJ-> hadifarnoud: try "address 2a01:4f8:1c17:5d80::1/64"  (note the 1)
[18:24] <hadifarnoud> does this include `2a01:4f8:1c17:5d80:78:47:223:238`
[18:27] <TJ-> hadifarnoud: 'address' specifies a specific address; If you want to use "2a01:4f8:1c17:5d80:78:47:223:238" then you'd want "address 2a01:4f8:1c17:5d80::78:47:223:238/64" - although I'm not sure how ifupdown handles IPv6 addresses with IPv4 identifiers
[18:29] <hadifarnoud> I think I set that IPv6 for my email server. probably need to set something that works with that
[18:47] <hadifarnoud> TJ- ^
[19:51] <Annoyed> Greetings
[19:56] <Annoyed> Two questions... I can disable the built in ntp sync daemon with " timedatectl set-ntp off ", install Chrony, start that, and that will sync the system clock along with providing ntp service to the inside network, correct ?
[22:13] <jayjo_> I have a gitlab instance that I want users to be able to push/pull from using ssh but I also want to be be able to access this server via ssh for maintenance tasks. Is there a way to do some sort of ssh proxying based on user or some other method to keep the default port 22 usable by both applications ?
[22:17] <TJ-> jayjo_: are there any ideas here you can adopt? https://stackoverflow.com/questions/33042817/have-sshd-forward-logins-of-git-user-to-a-gitlab-docker-container
[22:25] <jayjo_> thanks - that looks like an exact solution, using docker as well