David Tonhofer's questions

I'm installing FosWiki on a Fedora 40 Machine. The FosWiki top directory shall be /home/wikis/foswiki_company. Underneath that there are various directories for content, as well as the log directory.

/home is a separate filesystem (not NFS, just a separate partition on the local machine)

FosWiki is a cheap and cheerful bunch of Perl CGI scripts, so it's just the usual CGI setup.

It turns out that I cannot even get into the setup page of FosWiki because the setup script is unable to create the log file (i.e. Perl's open() call fails). The apparent problem is that "the filesystem is read-only".

SELinux is enabled and I'm checking the AVC denial messages. There seems to be none.

Below is the relevant structure of the filesystem.

• The orange elements are where the logfile is meant to go, but doing so proves to be impossible. I also tried with the tmp subdirectory, same problem.
• The brown element are an experiment whereby I modified the CGI script so that the log file would be written to a (suitably permission-ed) directory /home/tmp, which fails.
• The green elements are an experiment whereby I modified the CGI script so that the log file would be written to a (suitably permission-ed) directory /var/www/tmp. This works.

Additionally, the SELinux boolean for allowing httpd access to home directories, usually off, has been switched on, no difference, it seems to be irrelevant to this problem:

# semanage boolean -l -C
SELinux boolean                State  Default Description

httpd_can_network_connect      (on   ,   on)  Allow httpd to can network connect
httpd_enable_homedirs          (on   ,   on)  Allow httpd to enable homedirs
selinuxuser_execmod            (on   ,   on)  Allow selinuxuser to execmod

Additionally, if I su - apache (after configuring a shell for user apachein /etc/passwd), I can create or write to any of the log files.

So it's a process-related thing, not a user-related thing.

Additionally, I tried disabling SELinux, but got the same problem.

So it's unlikely to be SELinux.

What am I missing? What could stop Apache httpd from writing to the /home filesystem?

I have an external USB 3 "spinning rust" 2.5'' Harddisk.

Serial number lookup at Western Digital reveals this is a model WDBYNN0010BBL, "WD My Passport (Ultra) Portable Storage, Blue". 1 TB = 931.48 GB, cheap and cheerful. No data sheet. WD instrumentation software provides no way to find out more about the actual harddisk in the enclosure.

Although USB 3, I connect it to an USB 2 interface on the PC (it's an old PC).

I'm filling the disk with semi-random data, directly writing to the partition (i.e. /dev/sdd1 in Linux).

Problem:

Initially, the writing program reports a write performance of ~28 MiB/s (way below the max performance of USB 2, 50.7 MiB/s).

The writing program does nothing except write a chunk of data, then sync.

Once around 7 GiB have been written, write performance becomes flaky and starts to pogo between 8 MiB/s and 28 MiB/s.

After about 115-120 GiB have been written, write performance decays further to consistently hover at around 6 MiB/s, temporarily going as low as 2 MiB/s for a few hundred MiB.

However, once you suspend the program for half a minute (CTRl-Z) and then resume it, write performance goes back up to 28 MiB/s. And then after some time, the performance decays again.

Question:

Is there something in the construction of this disk which allows only short bursts of acceptable write speed? Does it pretend to be fast by having a large internal (nonvolatile) cache?

I have a number of other external USB disks (some from WD, although none that are of the exact same model) and they all manage to sustain 10+ MiB/s write speed, which makes backups at least viable as they can run in an afternoon instead of 24h.

Update #1

It is also running the latest firmware v1.019, as per "WD Firmware Updater" for Windows)

Update #2

"WD Drive Utilities" for Windows says it passes the S.M.A.R.T. test, the "quick drive test", and the "complete drive test". Nice!

Update #3

Filling the disk on another Linux machine via an USB3 interface upgrades the write throughput to 100 MiB/s. However, the decay is still there, going down to 33 MiB/s or even 9 MiB/s, so that at the end of the operation, the mean write throughput for the whole disk was just 30 MiB/s.

Update #4

smartctl --all /dev/sdd reveals:

Device Model:     WDC WD10SDZW-11UMGS0
Serial Number:    WD-WXT1A57EU75S
LU WWN Device Id: 5 0014ee 607b8ce4a
Firmware Version: 01.01A01 <--- HUH? I thought it was 01.019?? 
User Capacity:    1,000,171,331,584 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Dec  8 12:58:26 2019 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

All offline tests passed, reallocated sector count is 0 (though this may not mean much).

I was running Ubuntu 18.04 in a KVM VM on Fedora 30.

At some point the host machine got into trouble with Spice. The kernel of the host machine says:

Oct 20 14:16:46 host.name kernel: traps: SPICE Worker[22505] trap int3
ip:7f43f3c9e095 sp:7f43e8ffe1f0 error:0 in 
libglib-2.0.so.0.6000.7[7f43f3c63000+82000]

In the guest system log /var/log/libvirt/qemu/muh-ubuntu.log we find:

(process:22445): Spice-ERROR **: 14:16:46.760: 
red-parse-qxl.c:349:red_get_clip_rects: assertion 
`(uint64_t) num_rects * sizeof(QXLRect) == size' failed
2019-10-20 12:16:47.427+0000: shutting down, reason=crashed

The whole host GUI froze, then VM keeled over like a sick beluga.

Now the Virtual Machine image seems to have been seriously affected (surprise!). When I start it, I just get "error: attempt to read or write outside of disk `hd0'. Press any key to continue..." but keyboard input isn't even being accepted.

Is it foobared or is there some way to salvage something? (As in, access the filesystem in the VM image?)

I'm trying to install a pre-Iraq-Surge 4.4.9 PHP in a modern Apache 2.4.6 and want to run it in CGI mode.

The current configuration is as follows:

The PHP executable is /usr/local/php-4.4.9/bin/php

A test file exists in $documentroot/phphere/index.php of the virtual server, it contains:

<?php
 phpinfo();
?>

If I execute the index.php using php, all is hunky dory.

Running

/usr/local/php-4.4.9/bin/php $documentroot/phphere/index.php | less

yields

X-Powered-By: PHP/4.4.9
Content-type: text/html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html><head>
<style type="text/css">
body {background-color: #ffffff; color: #000000;}
body, td, th, h1, h2 {font-family: sans-serif;}
pre {margin: 0px; font-family: monospace;}
a:link {color: #000099; text-decoration: none; background-color: #

etc.

Excellent!

However, calling index.php via a web client results in this:

Warning: Unexpected character in input: '' (ASCII=1) state=1 in /usr/local/php-4.4.9/bin/php on line 277

Warning: Unexpected character in input: '' (ASCII=15) state=1 in /usr/local/php-4.4.9/bin/php on line 277

Parse error: syntax error, unexpected T_STRING in /usr/local/php-4.4.9/bin/php on line 277

which is exactly the output that one gets if one processes the php executable with itself, i.e. the output of

/usr/local/php-4.4.9/bin/php /usr/local/php-4.4.9/bin/php

(less any headers additionally generated).

Ok, so there is some problem in the Apache setup. But what?

The following is configured:

AddType application/x-httpd-php        .php
AddType application/x-httpd-php-source .phps

ScriptAlias /outsidephp             /usr/local/php-4.4.9/bin
Action      application/x-httpd-php /outsidephp/php

If I understand correctly, AddType tags any file ending in .php with MIME type application/x-httpd-php.

If PHP shall be run via CGI conventions, then the executable to run whenever a file with the MIME type application/x-httpd-php is requested is indicated with Action. The ScriptAlias gives an URL-path to the directory in which the php executable can be found. (This syntax sounds awkward though, why not have a single command for that?)

Additionally, the option ExecCGI has been set in the directory containing index.php and the SELinux contexts on that filesystem tree are marked with httpd_sys_script_exec_t.

Note that there is absolutely no

AddHandler cgi-script .php

in the configuration because THAT make Apache try to execute files ending in .php directly as scripts, which predictably fails with Error 500:

Error message:
End of script output before headers: index.php 

What's wrong exactly?

How do I make Apache run

php index.php

instead of

php php

(i.e. quite probably php php index.php)

Currently performing software archeology on an old-ish installation of MySQL 5.6. I have a few months of MySQL general query log, and would like to do a statistics on what queries are being run by whom how often, as various "undocumented" automata from all over have been set up to access said database. Do I have to go all Perl on this or is there a ready-made analysis tool?

I have a CentOS 7 server in a LAN together with Windows machines.

I have switched on logging in iptables of "to-be-rejected" or "to-be-dropped" packets using

firewall-cmd --set-log-denied=all

This adds the appropriate iptables logging rules. For example, at the end of the FORWARD chain:

LOG        all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID LOG flags 0 level 4 prefix "STATE_INVALID_DROP: "
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID
LOG        all  --  0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "FINAL_REJECT: "
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

However, now the kernel log (or rather the journal) logs lots of packets from the assorted Windows machines getting rejected, more precisely NetBIOS broadcasts (UDP to port 137 and 138 on the subnet broadcast address) that no service on the Linux box is interested in.

I want to just drop these packets without further ado even before they are logged.

FINAL_REJECT: IN=ens160 OUT= MAC=ff:ff:ff:ff:ff:ff:XX:XX:XX:XX:XX:XX:08:00 SRC=10.10.2.74 DST=10.10.2.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=32306 PROTO=UDP SPT=137 DPT=137 LEN=58

What is the firewall-cmd to do this properly?

I want to launch a Fedora 24 instance on Amazon EC2. The Fedora Cloud download page no longer offers links to Fedora 24 AMIs, instead it offers links to "Fedora 25 Atomic Host" images (these are new stuff, things are changing too fast nowadays).

On the Amazon EC2 Service Page, I can search for Fedora AMIs in the "Community AMIs" subset. This delivers a number of AMIs marked as "Fedora"

Why should I trust these images? How I can I find out whether they are the real deal?

I am right now getting additional grey hair fighting a phenomenon concerning packet loss between machines on the Internet.

Check the diagram below. Note that whenever I use "SSH" I could use "HTTPS"; the same phenomenon occurs for that protocol.

A SSH server running Fedora 22 is on "Site A" (wine red). I never had any connection problems till "recently".

SSH connections to "Site A" from Amazon EC2 machines running Fedora 22 or Fedora 23 work perfectly well (hosts shown in green inside the "Amazon EC2" box)

SSH connections to "Site A" from "Site B", which is on the same AS, do not work from any Fedora system I tested (orange boxes). However they do work from a Windows 7 system using Putty. The same (dual-boot) hardware is involved in both cases. "Site B" also has a firewall but that does not seem to play any role: I have tried to set up the connection directly from the FritzBox router and it still didn't work for Fedora but worked for Windows.

How does the problem manifest itself:

When you connect using SSH, there is an initial packet exchange going on (as shown by tcpdump). However, after 20 packets or so, the outgoing packets seem to not go anywhere anymore; no acknowledgements come back from Site A. You never get to the password prompt. A CTRL-C properly resets the connection, after which Linux still tries to send the packets that were never ACKed for a bit.

I suspect there is some problem at my ISP, in particular I suspect that the ISP performs suspect magic in order to implement the "fixed IP address" at Site B, which is the only thing that changed "recently".

However, I can't understand what would account for the fact an SSH connection works from Windows but not from Linux under the same conditions, network-wise. What should I be looking for?

• Here (Amazon S3) is the tcpdump of a failing SSH connection

Case of an Amazon EC2 Fedora 23 instance.

The file /etc/resolv.conf which determines how DNS lookups are performed by glibc resolver (see man resolv), looks as follows:

; generated by /usr/sbin/dhclient-script
search eu-west-1.compute.internal club
nameserver 172.31.0.2

• The nameserver 172.31.0.2 line points to the EC2-provided "DNS cache" on my private virtual local network, which is fine.
• The search line is bothersome because it instructs the resolver to try to resolve X.eu-west-1.compute.internal and X.club when it is being asked to resolve X. The eu-west-1.compute.internal domain comes from the fact that this is the suffix of the internally-used hostname: Looking up anything in that domain is pointless. The club domain comes from the fact that this is the suffix of the externally-used hostname: Looking up anything in that domain is pointless and possibly a security problem.

So I want to get rid of the search line.

Doing this elegantly apparently demands that I tell /usr/sbin/dhclient-script (see man dhclient-script) to not set it up in the first place.

A look at said script shows that I might modify it and comment out the bash function eventually_add_hostnames_domain_to_search or the calls to it, but is there a better way (some configuration option somewhere)?

Context

I have a Fedora 20 cloud image running on Amazon EC2 (henceforth called the "instance"). And I have some uncertainty about persistently setting its hostname.

Goal

In this case, let's say I want to set the instance's hostname to penpen.homelinux.org. (This name will also be registered at DynDNS using ddclient, but that is another aspect which we are not interested in here.)

The hostname can of course be set manually after boot completes (using hostnamectl among others). But we want to have the correct hostname set before the first login.

Traditionally, to persistently configure the hostname, one would modify the contents of /etc/hostname. Unfortunately this does not work here.

Default system behaviour

By default, the instance sets its hostname to an internal EC2 name. After boot, we can look at all the little different places that yield the hostname, and we find:

Kernel hostname via 'sysctl'                      : ip-10-164-65-105.ec2.internal
Kernel domainname via 'sysctl'                    : (none)
File '/etc/hostname'                              : contains 'ip-10-164-65-105.ec2.internal'
File '/etc/sysconfig/network'                     : exists but has no 'HOSTNAME' line
According to the shell                            : HOSTNAME = ip-10-164-65-105.ec2.internal
Nodename given by 'uname --nodename'              : ip-10-164-65-105.ec2.internal
Hostname ('hostname')                             : ip-10-164-65-105.ec2.internal
Short hostname ('hostname --short')               : ip-10-164-65-105
NIS domain name ('domainname')                    : (none)
YP default domain ('hostname --yp')               : [hostname --yp failed]
DNS domain name ('hostname --domain')             : ec2.internal
Fully qualified hostname ('hostname --fqdn')      : ip-10-164-65-105.ec2.internal
Hostname alias ('hostname --alias')               : 
By IP address ('hostname --ip-address')           : 10.164.65.105
All IPs ('hostname --all-ip-addresses')           : 10.164.65.105 
All FQHNs via IPs ('hostname --all-ip-addresses') : ip-10-164-65-105.ec2.internal 
Static hostname via 'hostnamectl'                 : ip-10-164-65-105.ec2.internal
Transient hostname via 'hostnamectl'              : ip-10-164-65-105.ec2.internal
Pretty hostname via 'hostnamectl'                 : 

So let's try to write to /etc/hostname ...

If one writes the desired hostname to /etc/hostname, this change is lost again at the next boot. Let's examine the boot process, which is performed by systemd.

Example run

Write rorororoor.homelinux.org to /etc/hostname, then reboot.

Using journald we find (Note that the log lines are not entirely orderd by time):

The boot process starts off with hostname as localhost then switches root, at which point the hostname becomes rorororoor.homelinux.org.

Dec 26 15:12:08 localhost systemd[1]: Starting Cleanup udevd DB...
Dec 26 15:12:08 localhost systemd[1]: Started Cleanup udevd DB.
Dec 26 15:12:08 localhost systemd[1]: Starting Switch Root.
Dec 26 15:12:08 localhost systemd[1]: Reached target Switch Root.
Dec 26 15:12:08 localhost systemd[1]: Starting Switch Root...
Dec 26 15:12:08 localhost systemd[1]: Switching root.
Dec 26 15:12:08 localhost systemd-journal[67]: Journal stopped
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journal[155]: Runtime journal is using 8.0M
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journal[155]: Runtime journal is using 8.0M
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journald[67]: Received SIGTERM
...........
Dec 26 15:12:12 rorororoor.homelinux.org kernel: SELinux: initialized
Dec 26 15:12:12 rorororoor.homelinux.org systemd-journal[155]: Journal started
Dec 26 15:12:08 rorororoor.homelinux.org systemd-cgroups-agent[128]: Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: No such file or directory
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: systemd 208 running in system mode.
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: Detected virtualization 'xen'.
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: Set hostname to <rorororoor.homelinux.org>.
Dec 26 15:12:10 rorororoor.homelinux.org systemd[1]: Failed to open private bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
Dec 26 15:12:11 rorororoor.homelinux.org systemd[1]: Mounted Debug File System.

We see that systemd sets the hostname to rorororoor.homelinux.org, evidently successfully as the log's host column changes. Some errors are issued, possibly because hostnamectl cannot contact DBus at this point in time.

I am not sure who does the namesetting here; some internal part of systemd? Anyway, continuing through the journal, we find that the hostname is set back to the EC2 internal name pretty soon:

Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] util.py[DEBUG]: Running command ('resize2fs', '/dev/xvda1') with allowed return codes [0] (shell=False, capture=True)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] cc_resizefs.py[DEBUG]: Resizing took 0.067 seconds
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] cc_resizefs.py[DEBUG]: Resized root filesystem (type=ext4, val=True)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] helpers.py[DEBUG]: config-set_hostname already ran (freq=once-per-instance)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] helpers.py[DEBUG]: Running config-update_hostname using lock (<cloudinit.helpers.DummyLock object at 0x2559210>)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] cc_update_hostname.py[DEBUG]: Updating hostname to ip-10-164-65-105.ec2.internal (ip-10-164-65-105)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] util.py[DEBUG]: Running command ['hostname'] with allowed return codes [0] (shell=False, capture=True)
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] __init__.py[DEBUG]: Attempting to update hostname to ip-10-164-65-105.ec2.internal in 1 files
Dec 26 15:12:33 rorororoor.homelinux.org cloud-init[485]: [CLOUDINIT] util.py[DEBUG]: Running command ['hostnamectl', 'set-hostname', 'ip-10-164-65-105.ec2.internal'] with allowed return codes [0] (shell=False, capture=True)
Dec 26 15:12:33 rorororoor.homelinux.org dbus-daemon[226]: dbus[226]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Dec 26 15:12:33 rorororoor.homelinux.org dbus[226]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Dec 26 15:12:34 rorororoor.homelinux.org systemd[1]: Starting Hostname Service...
Dec 26 15:12:34 rorororoor.homelinux.org dbus-daemon[226]: dbus[226]: [system] Successfully activated service 'org.freedesktop.hostname1'
Dec 26 15:12:34 rorororoor.homelinux.org dbus[226]: [system] Successfully activated service 'org.freedesktop.hostname1'
Dec 26 15:12:34 rorororoor.homelinux.org systemd[1]: Started Hostname Service.
Dec 26 15:12:34 rorororoor.homelinux.org systemd-hostnamed[598]: Changed static host name to 'ip-10-164-65-105.ec2.internal'
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd-hostnamed[598]: Changed host name to 'ip-10-164-65-105.ec2.internal'
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Started Initial cloud-init job (metadata service crawler).
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Starting Cloud-config availability.
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Reached target Cloud-config availability.
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal systemd[1]: Starting Apply the settings specified in cloud-config...
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] helpers.py[DEBUG]: Running config-update_etc_hosts using lock (<cloudinit.helpers.DummyLock object at 0x2559350>)
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] cc_update_etc_hosts.py[DEBUG]: Configuration option 'manage_etc_hosts' is not set, not managing /etc/hosts in module update_etc_hosts
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] helpers.py[DEBUG]: config-rsyslog already ran (freq=once-per-instance)
Dec 26 15:12:34 ip-10-164-65-105.ec2.internal [485]: [CLOUDINIT] helpers.py[DEBUG]: config-users-groups already ran (freq=once-per-instance)

Hostname setting here is done via the unit "systemd-hostnamed". The "unit file" for "systemd-hostnamed" is /usr/lib/systemd/system/systemd-hostnamed.service and contains:

[Unit]
Description=Hostname Service
Documentation=man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/hostnamed

[Service]
ExecStart=/usr/lib/systemd/systemd-hostnamed
BusName=org.freedesktop.hostname1
CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE

The program invoked by the above /usr/lib/systemd/systemd-hostnamed is actually a binary (WHY!). However source code can be found.

The point is that we are back at ip-10-164-65-105.ec2.internal

WHAT DO?