nafmo's questions

I have a working Apache setup on CentOS 7.6 using the standard Apache 2.4.6-88 package, using HTTP. I am trying to enable HTTPS on the server, and everything works, except for my RewriteEngine rules. I cannot find any mention anywhere about RewriteEngine not being supported for mod_ssl.

I enabled HTTPS by installing the mod_ssl package, and Apache is now serving both HTTP and HTTPS from the same setup. There is a VirtualHost declaration in /etc/httpd/conf.d/ssl.conf, I haven't touched that. The relevant part of my configuration looks like this:

# Set up Apache proxying
ProxyRequests Off
ProxyPreserveHost Off

# URLs to handle locally
# Apache built-ins
ProxyPass /icons !
ProxyPassReverse /icons !

# Handle local URLs through Apache
RewriteEngine On
RewriteRule ^/$ /index.cgi [L]
RewriteRule ^/favicon.ico /ssg/favicon.cgi [L,R]

ProxyPass /ssg !
ProxyPassReverse /ssg !
ProxyPass /index.cgi !
ProxyPassReverse /index.cgi !
ProxyPass /robots.txt !
ProxyPassReverse /robots.txt !

# Hand off everything else to the Varnish backend, which will in turn
# forward to the appropriate backend server process.
ProxyPass / http://localhost:6081/ retry=0
ProxyPassReverse / http://localhost:6081/

The proxying parts work, all URLs except for the ones listed with the "ProxyPass !" rules are handed off to the Varnish back-end.

The Rewrite part only works for HTTP, however. So http://myip/ will redirect to http://myip/index.cgi and http://myip/favicon.ico to http://myip/ssg/favicon.cgi. On HTTPS, it does not work, and is instead proxied to the Varnish backend (which promptly reports an error).

I must be missing something obvious here, but I can't for my life figure out what.

Enabling very verbose logs, it seems to just completely ignore the RewriteRule parts:

[Fri Dec 14 13:38:30.248204 2018] [core:trace5] [pid 90883] protocol.c(647): [client 10.0.30.15:54280] Request received from client: GET / HTTP/1.1
[Fri Dec 14 13:38:30.248282 2018] [ssl:debug] [pid 90883] ssl_engine_kernel.c(225): [client 10.0.30.15:54280] AH02034: Initial (No.1) HTTPS request received for child 21 (server fe80::c9d0:5dd9:c7ed:2045:443)
[Fri Dec 14 13:38:30.248297 2018] [http:trace4] [pid 90883] http_request.c(312): [client 10.0.30.15:54280] Headers received from client:
[Fri Dec 14 13:38:30.248301 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Host: 10.0.28.168
[Fri Dec 14 13:38:30.248303 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Connection: keep-alive
[Fri Dec 14 13:38:30.248305 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Cache-Control: max-age=0
[Fri Dec 14 13:38:30.248308 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Authorization: Digest username=\\"admin\\", realm=\\"Software Activation\\", nonce=\\"redacted\\", uri=\\"/\\", algorithm=MD5, response=\\"redacted\\", qop=auth, nc=0000002d, cnonce=\\"redacted\\"
[Fri Dec 14 13:38:30.248310 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Upgrade-Insecure-Requests: 1
[Fri Dec 14 13:38:30.248312 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.85 Safari/537.36 Vivaldi/2.2.1388.21
[Fri Dec 14 13:38:30.248315 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   DNT: 1
[Fri Dec 14 13:38:30.248316 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
[Fri Dec 14 13:38:30.248328 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Accept-Encoding: gzip, deflate, br
[Fri Dec 14 13:38:30.248383 2018] [http:trace4] [pid 90883] http_request.c(316): [client 10.0.30.15:54280]   Accept-Language: sv,en-US;q=0.9,en;q=0.8,nb;q=0.7
[Fri Dec 14 13:38:30.248513 2018] [authz_core:debug] [pid 90883] mod_authz_core.c(835): [client 10.0.30.15:54280] AH01628: authorization result: granted (no directives)
[Fri Dec 14 13:38:30.248542 2018] [core:trace3] [pid 90883] request.c(304): [client 10.0.30.15:54280] request authorized without authentication by access_checker_ex hook: /
[Fri Dec 14 13:38:30.248577 2018] [proxy_http:trace1] [pid 90883] mod_proxy_http.c(60): [client 10.0.30.15:54280] HTTP: canonicalising URL //localhost:6081/
[Fri Dec 14 13:38:30.248640 2018] [proxy:trace2] [pid 90883] proxy_util.c(1985): [client 10.0.30.15:54280] http: found worker http://localhost:6081/ for http://localhost:6081/
[Fri Dec 14 13:38:30.248657 2018] [proxy:debug] [pid 90883] mod_proxy.c(1123): [client 10.0.30.15:54280] AH01143: Running scheme http handler (attempt 0)

I am trying to figure out why a specific service is started on a system, and I wonder if there is a command to tell why a specific service was started?

When asking for status on the service, systemctl claims that it is disabled, yet it is running and I haven't explicitly asked to start it, AFAICT. Output below (slightly anonymized)

# systemctl status myservice
● myservice.service - My Service
   Loaded: loaded (/usr/lib/systemd/system/myservice.service; disabled; vendor preset: disabled)
   Active: active (running) since mån 2017-02-27 13:57:15 CET; 30min ago
     Docs: http://www.example.com/
 Main PID: 4680 (ewe)
   CGroup: /system.slice/myservice.service
           ├─4680 /opt/myservice/vbc/bin/myservice
           └─4944 /opt/myservice/vbc/bin/myservice

I am starting a service that has set Before=myservice.service in its .service file (no Requires), so I am suspecting that, but I can't tell for sure.

This is running on a CentOS 7.3 system.

EDITED: I have been able to work around the issue by making sure that a service that the above service has a Requires=, After= and Wants= relationship to, and which is started by a transient run-once service, is explicitly stopped. When doing this, the service is not started. I am not closer to figuring out why it was started in the first place, however.

EDITED: It seems that my service file is started whenever one of the services it has a Requires relationship to is restarted. I did not expect that to happen, I assumed that it would only mean that my service would start the other service when started, not that it would also start mine. Removing Requires fixes the phantom restarts.

I am installing Red Hat Enterprise Linux 7.0 Sever from a customized image with a Kickstart file. After rebooting, no product certificate has been installed, making it impossible to register the system.

I assume that I have inadvertently removed something from the install image that is necessary for creating this certificate file, but I am unable to figure out what.

After install:

# subscription-manager list
No installed products to list
# ls -l /etc/pki/product
total 0

I expected there to be a 69.pem file there, but none has been installed.

This is the kickstart file I am using currently (I've removed a lot of stuff from my original one, this one still causes the problem):

%packages
@core
httpd
lm_sensors
%end

%post
systemctl enable httpd.service
%end

reboot

I have also removed several packages from the Packages sub-directory, so it is entirely possible that one of the necessary packages might be missing. I've posted a full file list from the image on http://pastebin.com/M7bidk1G. All the files are taken from the original rhel-server-7.0-x86_64-dvd.iso file.

WORKAROUND: This is caused by us modifying the repo database on the ISO image (for adding our own RPMs), which somehow made Anaconda not identify the image as proper. I've added this workaround in the kickstart script:

cp /mnt/repodata/productid /etc/pki/product/69.pem

I am working on a web application that need to serve a number of continuously updated documents at static URLs, but the Content-Type of the documents differs (it's either JPEG or SVG). If the document is a symbolic link, the file at the end of the link has the correct file extension for MIME type mapping, but I have not been able to tell if it is possible to get Apache to follow the link before looking the extension up in the MIME table.

This question asks the same thing, but the workaround provided doesn't work for me, as browsers do not autodetect SVG if I serve image/jpeg (they do autodetect GIF and PNG), so I need a proper MIME type.

Normally, I would use .meta files and mod_cern_meta for this, but my target Linux distributions (Fedora 19/20, RHEL 7) does not come with this, and I would like to avoid having to supply it myself. I don't think I can use mod_headers, since it would require me to rewrite the entire .htaccess file (the files are changed on an individual basis), nor mod_asis, as the data files themselves are generated using a third-party tool.

Edit: I am working around this by writing my files as type-maps (with one entry only), pointing to the actual resource and listing its Content-Type. It means having to write extra files, but so would using mod_meta. Works well enough for the time being.