HOAB

Problem :

I was creating a simple cron job to connect to from remote-server-1 to remote-server-2.

Testing the job with direct call or run-parts was OK

# direct call to my script
/home/admin/myscript.sh

# or with run-parts
run-parts -v –-test /etc/cron.hourly

But when called from cron I had a : Permission denied (publickey).

Solution :

First, trying to reproduce in cron environment with this command line (extract from there)

I finally reproduce the problem.

So I add -vvv options to my ssh connection to get more details : still not enough clue : permission is refused.

Then I decided to compare my ssh connection from bash command line :

remote-server-1@myuser > ssh -vvv remote-server-2

What a surprise :

- it uses my personal key to connect to remote-server-2 instead of remote-server-1 key !

- my personal key is deployed on remote-server-1 and remote-server-2

So when I run the connection, it works because it uses my personal key but when ran from cron environment it uses remote-server-1 key and this one was not declared on remote-server-2.

SSH is able to use your connection key in priority to try to connect to another server...

Problem :

On Debian, do not update resolv.conf (DNS) when we have multiple DHCP network interfaces.

Solution :

A first link : Never update resolv.conf with DHCP client

But we don't want to never update, but sometimes update...

On Redhat families it's simple (see the previous link) : PEERDNS=NO on the right interfaces

On Debian families.... let's use the hook as suggested :

Create hook to avoid /etc/resolv.conf file update

You need to create /etc/dhcp3/dhclient-enter-hooks.d/nodnsupdate file under Debian / Ubuntu Linux:
# vi /etc/dhcp3/dhclient-enter-hooks.d/nodnsupdate
Append following code:

#!/bin/sh
make_resolv_conf()
{ : }

OK, but the hook prevent ALL interfaces to update resolv.conf, the idea :

1. in the hook test the interface name
2. if one authorized, call the original make_resolv_conf
3. otherwise to nothing

In bash it's not easy to have multiple function with the same name, but thanks stackoverlow !:

#!/bin/bash


# copies function named $1 to name $2
copy_function() {
    declare -F $1 > /dev/null || return 1
    eval "$(echo "${2}()"; declare -f ${1} | tail -n +2)"
}

# Import the original make_resolv_conf
# Normally useless, hooks are called after make_resolv_conf declaration
# . /sbin/dhclient-script

copy_function make_resolv_conf orignal_make_resolv_conf

make_resolv_conf() {
        if [ ${interface} = "auhtorizedInterface" ] ; then
                original_make_resolv_conf
        fi
}

Update :

The previous solution is not working...  declare is not known by sh/dash and the script is run by sh/dash. So the copy function is not possible.

Ideas :

• copy make_resolv_conf in this file under original_make_resolv_conf : it works, but ugly due to security patch not handled
• use 2 hooks : one enter : save resolv.conf, one on exit : restore resolv.conf if ${interface} is not authorized
• try to extract make_resolv_conf from /sbin/dhclient-script : not so easy...

Best solution, the two hooks, it's a pity :) I like the copy_functions :) :

# vi /etc/dhcp3/dhclient-enter-hooks.d/selectdns-enter

#!/bin/sh

cp /etc/resolv.conf /tmp/resolv.conf.${interface}

# vi /etc/dhcp3/dhclient-exit-hooks.d/selectdns-exit

#/bin/sh

if [ ${interface} = "auhtorizedInterface" ] ; then
       echo "${interface} not authorized"
       cp /tmp/resolv.conf.${interface} /etc/resolv.conf
fi

Problem :

I use bash as shell and usually the autocompletion (with bash-completion) works well.

Until I create some Include files...

Solution :

Not a final one for every one, but a quick workaround is :

1. put your Include file in a directory, for example : ~/ssh/config.d
2. add those config file in bash_completion configuration.

sudo vi /usr/share/bash-completion/bash_completion

// Add your directory in the config file list

for i in /etc/ssh/ssh_config ~/.ssh/config ~/.ssh/config.d/* ~/.ssh2/config; do
    [[ -r $i ]] && config+=( "$i" )
done

That's all folks.

Le problème :

Je joue avec des VM en ce moment, copie, clone, etc... et lors de la mise au point je me suis amusé à modifier le nom des volumes groups.... Dont le volume group qui hébergait la partition "/" :)

Alors après ça ne démarre plus... curieusement...

failed to connect to lvmetad

volume group "xxx" not found

Cannot process volume group "xxx" on boot

On arrive à la fin sur le initramfs qui indique bien la cause probable : boot args, cat / proc/cmdline

Et en effet, dans ce cas, le boot_image pointe vers l'ancien nom du volume group. Quoi de plus normal.

Mais bon j'ai un peu galéré pour un truc super simple à corriger.

Solution :

J'ai cherché des disques de dépannage dont le supergrub2-iso qui ne m'a pas aidé (pas réussi à le faire booter celui-là).

Bref, la solution toute simple (parce que j'ai grub2 !), au démarrage :

• booter une première fois jusqu'à avoir l'invite initramfs
• lister les volumes logiques : ls /dev/mapper
• repérer le nom du volume logique (qui contient -root en général)
• reboot de la vm
• lors du menu grub appuyer sur e pour éditer la configuration choisie
• repérer la ligne qui contient /dev/mapper/<ancien nom du volume logique>
• corriger le nom
• ctrl-x

ça devrait booter.

Pour corriger complètement :

1. Corriger le fichier /etc/fstab s'il contient encore la référence vers l'ancien volume logique
2. Vérifier le disque initfsram :

update-initramfs -u

# Si des warnings sont affiché, vérifier la configuration dans : 
cd /etc/initramfs-tools
# particulièrement :
/etc/initramfs-tools/conf.d/resume

3. Ensuite on demande à grub de se mettre à jour :

update-grub /dev/sda
grub-install /dev/sda

Problem :

After an update of my debian, I lost :

• power management icon
• multiple screen configuration and here
• background images and here
• media keys

And when I tried to apply new screen configuration I had :

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service

Many references on the net, many solutions :

1. reinstall cinnamon
2. remove configuration file
3. start /usr/bin/cinnamon-settings-daemon
4. ...

All tried, none work.

Solution :

Due to previous ressources and tests, I notice that when starting :

/usr/bin/cinnamon-settings-daemon

I had an error :

You can only run one xsettings manager at a time; exiting

After checking that is wasn't already started with :

ps -aef | grep cinnamon-settings-daemon

I perform a grep with :

ps -aef | grep settings

And I found that I had a gnome-settings-daemon running. Eurêka ! Gnome was my previous X manager.

So after a few checks :

sudo apt-get purge gnome-control-center gnome-settings-daemon gnome-control-center-data gnome-desktop3-data gnome-accessibility-themes

Restart, and all works.