The officially official Devuan Forum!

You are not logged in.

#1 Re: Desktop and Multimedia » ssh-tabbed xfce4-terminal » 2021-04-05 10:55:25

Thanks. That's quite useful. Much of it valid! The script obviously is a "works-for-me" kind of script smile

The line 36 note is misconceived though as that line actually needs the globbing and word splitting; the other ones are good if not terribly important.

And line 29 should rather include a sed filtering to discard all but the lilne numbers; I'm not sure a while loop will work since bash runs those in sub processes(?); does a history command in the sub change the history list of the parent?

But in any case I'll leave those improvements as exercise.

EDIT: also, the grep at line 29 should rather be grep -nFx "$TABBED" "$HISTFILE" to match the input verbatim (i.e., to avoid that it gets interpreted as a pattern).

#2 Desktop and Multimedia » ssh-tabbed xfce4-terminal » 2021-04-05 03:55:25

Replies: 2

If you use xfc4-terminal for running different ssh in its tabs, then this little scriptlet might suit you.

I have it set up to run in a launcher on the panel, for starting an xfce-terminal that begins by asking for the ssh command line arguments before connecting like so; an empty argument line  starts a local shell tab. Then the same happens on every C-S-T tab in that terminal. Quite handy.

File /home/ralph/bin/remote.xfce4

# Start an xfce4-terminal that runs ssh in each new tab, prompting for
# ssh command arguments, or drops to an interactive shell for empty
# arguments. Typically invoked by a launcher or a command line as
#     /whatever/the/path/remote.xfce4
# or with initial ssh arguments
#    /whatever/the/path/remote.xfce4 <arguments...>
# The script defines and uses the environment variable TABBED
# which gets cleared for a local shell.

if [ -z "$TABBED" ] ; then
    exec env TABBED="$*" xfce4-terminal -e $0 || exit 1
if [ -z "$TABBED" ] ; then
    HISTFILE=$HOME/.$(basename $0)
    history -r
    # The following line defaults to reusing the last ssh argument line
    TABBED="$(history -p "!!" )"
    read -e -i "$TABBED" -p "ssh: " TABBED
    if [ -z "$TABBED" ] ; then
	printf "\033]0;$(hostname)\007"
	[ -z "$SHELL" ] && SHELL=/bin/bash
	exec $SHELL -i || exit 1
    # The following 3 lines remove any prior duplicate ssh argument lines
    for N in $(grep -n "^$TABBED\$" $HISTFILE | sort -rn) ; do
	history -d ${N%%:*}
    history -s "$TABBED"
    history -w
printf "\033]0;${TABBED%% *}\007"
exec ssh $TABBED

Note that the history fiddling in the script, which makes the script look complicated, is not really required for the "tabbed ssh" functionality. It could be edited out, but it's there in order to make the ssh arguments input interaction "friendlier" by allowing for up/down arrow stepping through the history of such inputs.


EDIT: Note that the xfce4-terminal preferences also needs to be set up to run the script as custom command for tabs in order for the script (rather than shell) to be run for tabs.

#3 Re: Hardware & System Configuration » Devuan and OpenVPN » 2021-04-04 23:18:39

afaik you only need the openvpn package; the rest is just some GUI confusion overlay trying to make sure you don't know and understand what you are doing.

Then you need to generate a client key at the server end, and copy the client part to the client end.

And then you need the client configuration file to match up with the service. It's all well documented in man openvpn.

#4 Re: Off-topic » Music » 2021-04-04 12:25:35

I got nostalgic today and looked up some serious study music:

#5 Re: Other Issues » Can't upgrade my packages from's ftp server » 2021-04-04 00:54:13

It's both simple and confusing smile

The FQDN is an HTTP mirror collection. The servers in that group are only required to serve HTTP.

If there were several FTP servers it could be useful to craft an mirror collection, and likewise a possible, as well as perhaps even and

However, only HTTP allows the "HTTP 302 redirect" which tells the client to go elsewhere for package download.

Access for ftp, rsync, etc. requires the server either to house both Devaun and Debian packages themselves, or to have file access proxying. While the latter is not much of a technical challenge it means that any proxied packages would go in and out of the server and thereby doubling the bandwidth loading for them.

The option of housing Debian as well as Devuan is taken up by a couple of servers, typically by them adding Devuan to an already existing Debian mirroring. Then, to provide apt access for Devuan they also have the specially crafted root structure needed to handle the virtual pathnames of the Devuan merged packages.

#6 Re: Other Issues » Can't upgrade my packages from's ftp server » 2021-04-03 07:07:26

Afaik the package repositories are not provided over ftp anywhere; not sure how you got that idea.

The package file access relies on HTTP redirect as means for pulling packages from Devuan the store or the Debian store. The principle is simply that the filename for the package files has a prefix of either pool/DEVUAN or pool/DEBIAN and a server rewrite rule that maps the former into a local access whereas the latter is returned as an HTTP redirect to a service.

Some release iso mirrors offer different file access protocols such as ftp and rsync for the isos.

#7 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 13:32:24

Once done, how should I test that everything is working properly?

One confirmation would be that your fstrim logging shows up.

A manual forced test would be like before, i.e. if live-config is uninstalled, then

sudo /usr/sbin/anacron -s -d -n -f

should be telling about running the cron.{daily,weekly,monthly} jobs.

#8 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 13:01:12

Good. So when the start script runs /usr/sbin/anacron it actuallly runs /bin/true which is doing bugger all...

Possibly @fsmithred (who's doing refracta-base) knows something about that redirect but in any case it's wrong for your purpose.

The fix has two options:

The first option would be to change the link by:

sudo ln -sTf anacron.orig.anacron /usr/sbin/anacron

That will undo the redirect, but this then runs the risk of being undone, and the redirect comming back, if the live-config package is updated.

The second option would be to change /etc/init.d/anacron to use /usr/sbin/anacron.orig.anacron as binary; i.e., change start-stop-daemon --start command line to be

start-stop-daemon --start --exec /usr/sbin/anacron.orig.anacron -- $ANACRON_ARGS

The second option is probably a more sticky fix than changing the link, although it probably breaks if the live-config package is uninstalled.

EDIT: btw you might want to "verify" that anacron.orig.anacron is indeed the program by checking

$ md5sum /usr/sbin/anacron.orig.anacron
a16e182008f9105825af2580ab9e5ced  /usr/sbin/anacron.orig.anacron

#9 Re: Off-topic » is the subject of that open letter taboo? » 2021-04-01 04:05:02

For sure: everyone should inform themselves, but there are already many places where one can disccuss that, if one is so inclined. No reason to fill up this forum.

#10 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 02:21:32

The warning can be ignored. But I expected to see the output "Anacron 2.3 started on 2021-04-01" after the "transferring control", and not seeing that is peculiar... which architecture do you have?

uname -a
file /usr/sbin/anacron
file $(readlink -f /lib64/

#11 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 01:17:25

Right; that's the right one... next check would be first to verify that the problem is with anacron, by seeing

sudo /usr/sbin/anacron -s -d -n -f

report nothing.

Then try the following:

sudo env LD_DEBUG=libs,files /usr/sbin/anacron -s -d -n -f >& /tmp/strace.log

... and paste somewhere

That should be a debug listing of the loading of dynamic libraries including how they are looked up in the file system.

#12 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 00:52:19

Hmm. obviously your /usr/sbin/anacron dies before it starts, or while it about to start, seemingly at the point where it should allocate memory.

However the "brk(NULL)" which should follow "munmap()" doesn't show up and instead the "exit_group()" showing premature exiting, and that suggests borked linking rather than out of memory; i.e., a technological mismatch with the dynamic libraries rather then a functional error.

Which libc6 do you have?

ls -l /lib*/ld-linux-*

#13 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 00:11:29

|   |   |-grep,13714 --color=always -A 3 anacron

that was the grepping itself, so no "real" anacron running.

Try again with

sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f

and verify that that only gives that same one line of output...

Check then at end of /var/log/syslog to see if there's an explanation.

Following that we'll need to go deep diving with

sudo strace -f start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f >& /tmp/strace.log 

Possibly you'll need to install the strace package first.

That log will be long as it includes all the system calls by the execution, so the best is if you can paste it somewhere rather than include here. It looks like there's something just a little bit off on your system and this will give as a haystack to look in.

#14 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 23:08:07

My test showed nothing ...

But I realized that your forced running only resulted in a "Starting..." message, and not like the expected

$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f
[sudo] password for ralph:
Starting /usr/sbin/anacron...
Anacron 2.3 started on 2021-04-01
Will run job `cron.daily'
Will run job `cron.weekly'
Will run job `cron.monthly'
Jobs will be executed sequentially
Job `cron.daily' started
Job `cron.daily' terminated
Job `cron.weekly' started
Job `cron.weekly' terminated
Job `cron.monthly' started
Job `cron.monthly' terminated
Normal exit (3 jobs run)

Which package version do you have?

apt-cache policy anacron |& grep Installed

Is there an anacron running?

pstree -ap | grep -A 3 anacron

#15 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 22:42:33

Btw, re logrotate.conf since 18 and 25 are duplicates you might want to compare with the lines before those.

#16 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 22:26:53

You seem to mix up non-root and root user; the user's cron jobs ar run as that user and only root's cron jobs are run as root.

The anacron problem is not that problem, since it gets run by root.

#17 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 22:38:59

I keep my apparmor purged. I would purge selinux too had it been possible; it stays disabled.

For testing you might want to try changing /etc/default/anacron to say


just for the possibility that anacron misreads something.

Then, you might try, as root, a manual run to see if it says something

# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d

and then even a forced run ignoring date stamping

# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f

I'm running out of ideas sad ...
I've set up an anacron test myself now and we'll see in a couple of days if I have a similar problem.

#18 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 21:01:32

Ok that looks like the "normal" installed files. Hmmmm....

Do you use apparmor or selinux? Either one can do ugly things.

#19 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 10:27:49

Peculiar. Yes, the run-parts .. command if run as root would avoid the permission errors, but your test shows that the dev-fstrim does get invoked, which is enough of detail.

yes, you can use /var/log/WTF for persistent logging.

Peculiar. How do your /etc/anacrontab and /etc/default/anacron look?

#20 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 00:25:16

So apparently the anacron start/stop script gets invoked every hour as it should, but it fails to perform.

Add set -x on a line after your added date ... in /etc/init.d/anacron, and then wait for next invocation which now logs the whole script execution to /tmp/WTF. This in particular should have the line:

+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s

Seeing that to be so you would next try to force run the weekly scripts again. First ensure any previous run has completed, with

pgrep -a run-parts

returning nothing, and then use

run-parts --verbose /etc/cron.weekly

to see the new, forced weekly run happening.

#21 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 23:08:09

Ok. cron.log shows that it finds and loads and processes the /etc/cron.d/anacron scheduling, which would trigger the start/stop script if

  1. there is an executable /etc/init.d/anacron (script), and

  2. the pathname /run/systemd/system is not a directory (eg doesn't exist)

To verify that you would add the following two lines into the script /etc/init.d/anacron:

exec 2>>/tmp/WTF
date -R >&2

just after the PATH=... line.

That should cause an hourly logging to appear in the file /tmp/WTF, and that file will also contain any other stderr output that the script run generates.

In detail: the exec 2>>/tmp/WTF line associates standard error (for this script run) in append mode with the file, and the date -R >&2 line makes the date program issue a time stamp in RFC 5322 format to standard error. Any further error message from the script will be appended subsequently.

#22 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 21:20:32

Good. As you might know, anacron is supposed to provide the extended cron function to make sure that the regular scripts are run even if the machine happens to be down at the nominal trigger time. Since the scripts are not run it is possible that this "chain of control" is broken; that cron fails to run anacron or that anacron fails to run the script(s).

The running of anacron is typically set up using the sysvinit start/stop script, once initially at  boot up, and then regularly by cron with the schedule contol script /etc/cron.d/anacron. Afaict looking at my such script, it includes the particual misfeature of not running anacron imperatively but rather making this dependent on the absence of something. (A small-brain idea appearing as attempted solution to cater for a range of possible installation sites other than this one, but not bad enough for the effort of forking the package)

So, if that something is present then your set up does not run anacron as it should and consequently your weekly script won't be run "automatically". Similarly the boot up run of the script only happens at boot up if it's set up so.

If the preconditions for the regular run/start of anacron are there, the next point of call would be to review and confirm anacron local configuration, at both /etc/anacrontab and /etc/default/anacron. And for debugging purposes also add/change the start/stop script so that it makes some output to, say, /tmp/WTF (eg a date stamp) whenever it's run. Further, to speed up the testing cycle you might set it up for daily trimming rather than weekly since the auto-magic is supposedly the same for that (as configured in the typical installed /etc/anacrontab).

#24 Re: Hardware & System Configuration » [SOLVED] Changing a parameter in /sys/module » 2021-03-27 12:50:24

Create a file named /etc/modprobe.d/iwlwifi.conf with content

options enable_ini=N

See man modprobe.d for details.
(That man page belongs to the kmod package, which may and might not be installed)

#25 Re: Installation » Non Booting GRUB on Beowulf » 2021-03-26 20:48:27

Some months ago I used rEFInd to rescue an old mac mini; it might work for your troubles too...

Board footer

Forum Software