simon.schönbeck.dk

Tag: file

  • KDE Plasma sunrise (bright) & sunset (dark) theme automatic switch

    Under System Settings > Appearance & Style > Colours & Themes > Night Light in KDE Plasma there is the expected option to automatically switch at specific times between cool and warm colour temperature for the screen. I marked my location on the map and selected Sunset and sunrise at manual location to take care of the switch automatically. This works perfectly!

    For whichever reason, and there is many, KDE Plasma cannot do the same with the bright and dark theme. This is such a miss that one wonders how anything ever gets agreed upon in large open source projects such as KDE in this case. Gnome supports the option as many other.

    As there are more ways than one to skin a cat, I had several choices to work around this missing feature. I was really looking for something quick and dirty, nothing to install and trust, and easy to undo if needed.

    I decided to use the colour temperature as an indicator of when the bright or dark theme was needed. So at 6500 K it was the cool day light temperature and the bright theme should be used. On the contrary anything below this temperature, that is warm night light, should use the dark theme. Then I would simply check for this system value at a set interval and change the theme if it changed. This simple script is placed in the System Settings > System > Autostart section as an Application and it will launch upon boot and run in the background. Copy or download & unzip the below file and remember to make the .sh file executable:

    #!/bin/bash

    current_theme=""

    while true; do
      # Retrieve the current temperature from KWin using dbus-send
      temperature=$(dbus-send --session --dest=org.kde.KWin --type=method_call --print-reply \
        /org/kde/KWin/NightLight org.freedesktop.DBus.Properties.Get string:org.kde.KWin.NightLight string:currentTemperature \
        | grep -oP 'variant\s+uint32\s+\K\d+')

      # Decide the target theme based on the temperature
      if (( temperature == 6500 )); then
        target_theme="org.fedoraproject.fedora.desktop"  # Light theme for == 6500
      elif (( temperature < 6500 )); then
        target_theme="org.kde.breezedark.desktop"  # Dark theme for < 6500
      fi

      # Switch theme only if it's different from the current one
      if [[ "$target_theme" != "$current_theme" ]]; then
        lookandfeeltool -a "$target_theme"
        # Update the current theme to the new one
        current_theme="$target_theme"
        # KDE notification
        notify-send "Theme Switcher" "Switched to $(basename "$target_theme") theme."
      fi

      # Sleep for 15 minutes (900 seconds)
      sleep 900
    done
    Download shell script

  • Console recursive FTP client

    Sometimes data needs moving from server to server without FXP support. For this task there is nothing simpler than good old FTP.

    What about if you have a large number of subdirectories? As the plain FTP client can not fetch the files recursively shell scripting is usually the solution. But in cases where you do not really know neither the depth of the recursion or the naming convention of the file system structure, an alternative method is needed.

    This method is named NcFTP Client. I got to know about it today as I quickly needed to copy several gigabytes of data spread over several subdirectories and NcFTP did its job flawlessly. I did not even have to install it as Fedora 10 already came with it by default.

  • Virtualmin & suEXEC

    If by chance you have installed the Webmin module Virtualmin at some point you may have come across the following error message when setting up the module:

    Failed to save enabled features: The Suexec command on your system is configured to only run scripts under /var/www, but the Virtualmin base directory is /home. CGI and PHP scripts run as domain owners will not be executed.

    This error message is caused by using a version of suEXEC compiled by default to use /var/www as the document root of Apache. The suEXEC feature allows to execute scripts as the user owning the virtual host instead of the global apache user increasing security. The solution has either been to recompile suEXEC with the new desired path (/home in this case) or simply disable (Server Templates > Apache Website > Automatically add appropriate SuExec directive?) suEXEC completely inside the Virtualmin module configuration.

    A much simpler approach I used was to create a link between the two directories. I used mount to bind the two directories together and act as one. Voila, Virtualmin now continued the module setup without a remark!

    To achieve this I ran the following command as root:

    mount --bind /var/www /home

    That is it really. Now the directories act as one for the suEXEC wrapper too.

    Please note this will usually only last till next reboot. To mount permanently include the following line into your /etc/fstab:

    /var/www /home none bind

    The following is the extract from the mount man page:

    Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
    mount --bind olddir newdir
    or fstab entry is:
    /olddir  /newdir  none  bind
    After this call the same contents is accessible in two places.  One can also remount a single file (on a single file).

    One note is that if you already had local users set up inside the /home directory you will mount on top of it, making the existing users data unavailable (not deleted). Simply unmount again and the users data will be back again. To get around this change the default path Virtualmin uses to create new virtual hosts home directories to something else e.g. /virtualmin. This can be done in the Users & Groups module.

  • Error: Could not open the local file – FTP madness!

    Trying to move some automatic backups from one location to another became a bit of a struggle recently. The backups are created automatically and uploaded to a file server at a scheduled pattern. From this file server I had to use some of the backups and tried to download them to my local machine. This is where the problem started.

    I am long time user of the excellent FTP client named FileZilla and very seldom experience any issues with it. But this time during the download process I kept receiving this weird error message:

    Error:    Could not open the local file path/filename
    Error:    Download failed

    I initially thought about some permission problems like no read access until I swiftly realised it was actually on the local side the issue was and not on the server. This just made no sense as obviously why would it want to open the file when it actually had to create the file instead. I tried to download the backups to different locations on the hard disks, even external ones as well, to see if oddly enough they had magically become write protected. This was not successful and I started to think of the directory structure as downloading the individual file worked just fine.

    So to summarise:

    1. Downloading the directory containing the backups did not work.
    2. Downloading each individual file inside the directory worked as expected.

    Very strange indeed…

    I actually did not break it until the following morning when I woke up with the solution. I am not sure what happened as I would not dream about such a pity issue but I just woke up and Eureka!

    In hindsight it was really obvious what the problem was but at the point it just did not come to my mind.

    Linux and Windows have some dramatic differences and one of them is the fact that file and directory names under Windows are limited to certain characters while Linux pretty much takes it all. I was trying to download directories to a Windows XP PC with a colon (:) in the name, such as . This is incompatible with Windows and therefore FileZilla was not permitted to create such directories anywhere on the hard disks.

    Never use the following characters in file or directory names if you expect Windows compatibility:

    / \ : * ? " < > |