Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
fuss:debian [2020/07/28 01:41] – [Recompile Debian Kernel] officefuss:debian [2025/08/17 20:14] (current) – [Fixing PHP FPM Binary Version] office
Line 412: Line 412:
 </code> </code>
  
 +====== Disable nftables and Continue Using Legacy iptables ======
  
 +<code bash>
 +update-alternatives --set iptables /usr/sbin/iptables-legacy
 +update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
 +update-alternatives --set arptables /usr/sbin/arptables-legacy
 +update-alternatives --set ebtables /usr/sbin/ebtables-legacy
 +</code>
 +
 +====== Fix Issues on Release Change ======
 +
 +When a repository changes its release data the following error should appear when updating packages:
 +<code>
 +This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details
 +</code>
 +
 +the solution is to run ''apt'' as:
 +<code bash>
 +apt-get update --allow-releaseinfo-change
 +</code>
 +
 +with the extra ''--allow-releaseinfo-change''.
 +
 +====== Ensuring HostAPd is Started Only After the Bridge Interface ======
 +
 +On Debian, bridging the wireless interface to a bridge involves using ''hostapd'' and configuring ''hostapd'' to bridge the wireless interface to a bridge. Unfortunately, given a complicated setup, it might happen that ''hostapd'' is started too soon, especially if the machine already has a configured bridge, such that the ''hostapd'' service file has to be changed in order to wait for both interfaces.
 +
 +In order to do this, copy ''/usr/lib/systemd/system/hostapd.serivce'' to ''/etc/systemd/system/'' and then edit the file to [[/fuss/systemd#make_service_depend_on_network_interface|make systemd wait]] for the bridge and wireless interface before running hte service file.
 +
 +Assuming ''br0'' is the bridge interface and ''wlan0'' is the wireless interface, the ''hostapd'' service file at ''/etc/systemd/system/hostapd.conf'' is modified to match the following:
 +<code>
 +[Unit]
 +Description=Access point and authentication server for Wi-Fi and Ethernet
 +Documentation=man:hostapd(8)
 +BindsTo=sys-devices-virtual-net-br0.device
 +After=sys-devices-virtual-net-br0.device sys-subsystem-net-devices-wlan0.device
 +ConditionFileNotEmpty=/etc/hostapd/hostapd.conf
 +
 +[Service]
 +Type=forking
 +PIDFile=/run/hostapd.pid
 +Restart=on-failure
 +RestartSec=2
 +Environment=DAEMON_CONF=/etc/hostapd/hostapd.conf
 +EnvironmentFile=-/etc/default/hostapd
 +ExecStart=/usr/sbin/hostapd -B -P /run/hostapd.pid $DAEMON_OPTS ${DAEMON_CONF}
 +
 +[Install]
 +WantedBy=multi-user.target
 +
 +</code>
 +
 +====== Enabling Wireless Network Roaming using ifupdown and wpasupplicant Roaming ======
 +
 +Wireless network roaming is a mechanism through which wireless clients (computers, laptops, etc.) change their network depending on the wireless networks that are currently available. Roaming can be accomplished easily on Linux using ifupdown and plain wpasupplicant by first configuring the wireless interface and then adding networks to the wpa supplicant configuration.
 +
 +For example, here are the contents of the file ''/etc/network/interfaces.d/wlan0'' that set up the ''wlan0'' interface using ''wpa_supplicant'':
 +<code>
 +auto wlan0
 +allow-hotplug wlan0
 +iface wlan0 inet manual
 +        wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
 +
 +iface default inet dhcp
 +
 +</code>
 +
 +The file defines the network interface ''wlan0'' and points the interface to the WPA supplicant configuration file ''/etc/wpa_supplicant/wpa_supplicant.conf'' using the ''wpa-roam'' configuration key. 
 +
 +The line ''iface default inet dhcp'' defines a catch-all network ''default'' telling ifupdown to use DHCP for any network that is not well-defined within the wpa_supplicant configuration file at ''/etc/wpa_supplicant/wpa_supplicant.conf''.
 +
 +The next part is to set up ''wpa_supplicant'' by editing the file ''/etc/wpa_supplicant/wpa_supplicant.conf'' and adding networks. Here is a sample configuration file:
 +<code>
 +ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
 +update_config=1
 +country=IS
 +
 +network={
 +        ssid="a"
 +        #psk="password"
 +        psk=
 +        priority=1
 +        id_str="wifi_a"
 +}
 +
 +network={
 +        ssid="b"
 +        #psk="password"
 +        psk=...
 +        priority=2
 +        id_str="wifi_b"
 +}
 +
 +network={
 +        ssid="c"
 +        #psk="password"
 +        psk=...
 +        priority=3
 +        id_str="wifi_c"
 +}
 +
 +</code>
 +
 +that defines three Wifi networks with SSIDs, ''a'', ''b'' and ''c'' (with the credentials trimmed out for brevity). The ''network'' block can also be generated automatically using ''wpa_passphrase'' and appended to the ''/etc/wpa_supplicant/wpa_supplicant.conf'' file.
 +
 +Note that the markers ''wifi_a'', ''wifi_b'' and ''wifi_c'' corresponding to the configuration key ''str_id'' are identifiers that can be used to refer to the network within the ifupdown configuration file. For example, suppose that the Wifi network ''wifi_c'' with the SSID ''c'' needs to be configured manually using an IP address and netmask. Returning to the ''/etc/network/interfaces.d/wlan0'' ifupdown scripts, the configuration will then change to match the following:
 +<code>
 +auto wlan0
 +allow-hotplug wlan0
 +iface wlan0 inet manual
 +        wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
 +
 +iface default inet dhcp
 +
 +iface wifi_c inet manual
 +    address 192.168.0.1
 +    netmask 255.255.255.0
 +
 +</code>
 +where ''wifi_c'' corresponds to the Wifi network with SSID ''c'' within the ''wpa_supplicant'' configuration file ''/etc/wpa_supplicant/wpa_supplicant.conf''.
 +
 +====== mod_qos & Others Undefined Symbol ======
 +
 +As rare as it may be, sometimes Debian packages are broken and the built binaries reference libraries that are not available on the current system. As an example, here is the ''libapache2-mod-qos-11.64'' on Debian stable "Bookworm" not working due to referencing an older PCRE library:
 +<code>
 +mod_qos.so: undefined symbol: pcre_free
 +</code>
 +
 +One solution is to attempt and upgrade the package to "testing" or "unstable" by using ''apt-cache policy PACKAGE'' where ''PACKAGE'' is the name of the package, followed by ''apt-get install PACKAGE=VERSION'' where the additional ''VERSION'' is the version of the package to upgrade to, but that might not work out so well due to the new package requiring additional dependencies to be installed that might end up in dependency hell.
 +
 +A better solution is [[/linux/recompile_debian_packages|to just recompile the package, the Debian-compliant way]], and install it temporarily till the usual Debian update pipeline updates it to a fixed package. The package should be the newer package that has been fixed in the "unstable" or "testing" branches and the recompiling will just take care to use the existing libraries such that the Debian release does not have to be bumped.
 +
 +====== Get Debian Version ======
 +
 +The following release should display the current Debian version: 
 +
 +<code bash>
 +lsb_release -a 
 +</code>
 +
 +====== Quick Way to Install All Packages from One Machine Onto the Other ======
 +
 +Using some command-line tools while logged in on ''MACHINE_A'', issue the command:
 +<code bash>
 +dpkg --get-selections | grep 'install' | awk '{ print $1 }' | xargs ssh root@MACHINE_B apt-get -y install
 +</code>
 +that will get all the installed packages from ''MACHINE_A'', then SSH into ''MACHINE_B'' and install all packages from ''MACHINE_A''
 +
 +The transfer is sometimes useful in situations where the same set of packages have to be used across a cluster of nodes, or some uniformity is desired across several machines, such as within a docker swarm.
 +
 +====== Retrieve an Original File from the Debian Repository ======
 +
 +The following command will create a command-line alias named ''dist-file'' that takes as parameter the path to a file on the local filesystem, retrieves the original version of that file from the Debian repository and displays it.
 +<code bash>
 +dist-file() { dpkg -S /etc/apache2/ports.conf | awk -F':' '{ print $1 }' | xargs -I{} apt-get install --reinstall --print-uris -qq {} | grep -Po "'(.+?)'" | xargs -I{} curl -s '{}' -o - | dpkg-deb --fsys-tarfile - | tar -xO ".""$1"; }
 +</code>
 +
 +In order to use the alias, just copy-paste the above line into a terminal and press return. If successful, the command will produce no output.
 +
 +The alias is pretty useful for system administrators that have changed service configuration files and would like to retrieve the original file in order to compare with the local file. The alias can of course be piped into ''diff'' in order to see the actual changes. 
 +
 +For example, the following command will display that changes between the original package file at ''/etc/apache2/apache2.conf'' and the current file at ''/etc/apache2/apache2.conf'' in Bakus-Naur form:
 +<code bash>
 +dist-file /etc/apache2/apache2.conf | diff -Naur - /etc/apache2/apache2.conf
 +</code>
 +and it thus shows any local changes that have been made to the main Apache2 configuration file.
 +
 +The version above picks the currently available Debian package according to distribution settings (oldstable, stable, unstable, experimental, etc.) but to be correct, the file to retrieve should correspond to the actual version of the package that is installed, not just the first available one. For that, the following alias should be able to retrieve the file corresponding to the currently installed package version:
 +<code bash>
 +dist-file-exact() { dpkg -S $1 | awk -F':' '{ print $1 }' | while read -a PACKAGE; do apt-get install --reinstall --print-uris -qq "${PACKAGE[0]}="$(dpkg-query -f '${Version}' -W "${PACKAGE[0]}"); done | grep -Po "'(.+?)'"  | head -1  | xargs -I{} curl -s '{}' -o - | dpkg-deb --fsys-tarfile - | tar -xO ".""$1"; }
 +</code>
 +
 +However, be aware that the ''dist-file-exact'' alias will error in case the file is within a package version that is not available for download anymore via the currently configured apt sources (this means that the distribution should be upgraded).
 +
 +====== Filtering Interfaces and Protocol Version in IfUpDown Scripts ======
 +
 +IfUpDown scripts run once an interface is added, removed, but also when a given protocol link has been established such as IPv4 or IPv6 such that it is necessary to filter for both in order to ensure that a script runs once.
 +
 +For example, the following script added to ''/etc/networking/if-up.d'':
 +<code bash>
 +#!/bin/sh
 +
 +[ "$IFACE"   = "usb0" ] || exit 0  # we only want interface "usb0"
 +[ "$ADDRFAM" = "inet" ] || exit 0  # we only want IPv4 (not "inet6" for IPv6)
 +
 +brctl addif br0 usb0
 +
 +</code>
 +will filter events for the addition of the ''usb0'' interface and will run the script only when the IPv4 link is established.
 +
 +Iff. the interface being brought up is ''usb0'' and the protocol is IPv4 then the ''usb0'' interface will be added to the bridge ''br0''.
 +
 +====== Fixing PHP FPM Binary Version ======
 +
 +For most versioned binaries on Debian, the convention is that the current version of the binary is a symlink that points to the actual binary version being installed. The clearest base-case example is the Linux kernel that appears on the root ''/'' partition as a link, named ''vmlinuz'' for example, to the kernel that is stored on the ''/boot'' partition. The idea is that while kernel versions might change, the symlink will always reference the latest active kernel. The same concept is usually carried over for all binaries, but in particular, where different versions of binaries might be meaningful, for example, for programming SDKs where a different version might mean a different API set.
 +
 +The problem is that PHP FPM, the CGI binary that can be used to process PHP for Apache, while it does have a generic package name, namely ''php-fpm'', the actual binary and then directory paths contain the version number, such that it becomes cumbersome to execute the binary or reference paths to the configuration. That means, when the ''php-fpm'' package is installed via ''apt-get install php-fpm'', the package ''php8.2-fpm'' in-turn is installed, which results in the following binaries and path that contain the version numbers in their name:
 +
 +  * ''/usr/sbin/php-fpm8.4'' the actual PHP FPM binary (there is no ''php-fpm'' binary linked to ''/usr/sbin/php-fpm8.4'')
 +  * ''/etc/php/8.4/'' the path to the PHP FPM configuration,
 +  * ''/etc/apache2/conf-available/php-fpm8.4.conf''
 +
 +The Apache2 configuration that instructs Apache on how to run PHP FPM at ''/etc/apache2/conf-available/php-fpm8.4.conf'' also contains references within the file to the PHP FPM binary and the path to the configuration that contain the version names. This means that on every upgrade the ''/etc/apache2/conf-available/php-fpm8.4.conf'' file will have to be removed and a new one created that references the current PHP FPM version.
 +
 +In case the configuration is fixed, such as [[/networking/leveraging_docker_swarm_for_high-availability_and_load-balancing_services|running Apache2 within Docker as part of LAMP stack]], rebuilding the container becomes a nightmare because installing ''php-fpm'' will not adjust the Apache2 configuration.
 +
 +The obvious solution is to create symlinks to the paths and current PHP FPM binary. For example, the following command is executed while building a Docker LAMP container after installing PHP FPM:
 +<code bash>
 +# link current php-fpm version to a static name
 +find /usr/sbin/ \
 +    -type f \
 +    -regextype posix-extended \
 +    -regex "/usr/sbin/php\-fpm[0-9\.]+?" \
 +    -exec ln -sf '{}' /usr/sbin/php-fpm \; && \
 +find /etc/php/ \
 +    -type d \
 +    -regextype posix-extended \
 +    -regex "/etc/php/[0-9\.]+" \
 +    -exec ln -sf '{}' /etc/php/current \;
 +</code>
 +
 +and the commands create the following symlinks for, say, PHP FPM 8.4:
 +  * ''/usr/sbin/php-fpm'' to ''/usr/sbin/php-fpm8.4'',
 +  * ''/etc/php/current/'' to ''/etc/php/8.4/'' 
 +
 +Now, the binary and path can be referenced on the command-line without caring which PHP FPM version is installed because the symlinks will always refer to the version that is currently installed. For example, running PHP FPM becomes a matter of:
 +<code bash>
 +# start php cgi server
 +/usr/sbin/php-fpm \
 +    --nodaemonize \
 +    --fpm-config /etc/php/current/fpm/php-fpm.conf \
 +    &
 +
 +# wait for socket
 +while [ ! -S /run/php/php*-fpm.sock ]; do
 +    sleep 1
 +done
 +
 +find /run/php/ \
 +    -type s \
 +    -regextype posix-extended \
 +    -regex "/run/php/php[0-9\.]+?\-fpm.sock" \
 +    -exec ln -sf '{}' /run/php/php-fpm.sock \;
 +
 +</code>
 +
 +where the last ''find'' command also symlinks the PHP FPM socket versioned file-name to a PHP FPM file name without the version.
 +
 +Lastly, the Apache2 PHP FPM configuration file ''/etc/apache2/conf-available/php-fpm.conf' has to be adjusted to reference the PHP FPM binary without a version within the file name.

fuss/debian.1595900474.txt.gz · Last modified: (external edit)

Wizardry and Steamworks

© 2025 Wizardry and Steamworks

Access website using Tor Access website using i2p Wizardry and Steamworks PGP Key


For the contact, copyright, license, warranty and privacy terms for the usage of this website please see the contact, license, privacy, copyright.