cron-apt

Im więcej mamy pod opieką serwerów bądź też nie logujemy sie na nie codziennie warto wiedzieć kiedy pojawią się jakieś aktualizacje. Tym bardziej gdy (jak ja) nie jesteśmy zwolennikami automatycznych aktualizacji.
Z pomocą przychodzi cron-apt, aplikacja która jak nazwa sugeruje wg ustawień crona sprawdza bądź aktualizuje nasz system, do tego dochodzi opcja powiadomień mailowych.

Instalacja:

apt install cron-apt

Konfiguracja (najprostrza – powiadomienie na mail o dostępnych aktualizacjach):

cat /etc/cron-apt/config
# Configuration for cron-apt. For further information about the possible
# configuration settings see /usr/share/doc/cron-apt/README.gz.
MAILTO="user@mail.com"
MAILON="upgrade"

Kiedy odpalamy:

cat /etc/cron.d/cron-apt 
#
# Regular cron jobs for the cron-apt package
#
# Every night at 4 o'clock.
0 4 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
# Every hour.
# 0 * * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2
# Every five minutes.
# */5 * * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2

Inne opcje:

/usr/share/doc/cron-apt/README.gz

 

Thunderbird: Tries to migrate non-existing .icedove folder

#857112 bug uniemożliwia uruchomienie thunderbirda, póki zaktuaizowana paczka nie pojawi się w reozytorium można ręcznie zastosować workaround:

This is due to an error in the script/usr/bin/thunderbird:
You cannot use the \ to merge multiple lines AND have a comment:
ie:
elif { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \
# .icedove exists as folder or symlink
     { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; } && \
# .thunderbird exists as folder or symlink
       [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "${ID_PROFILE_FOLDER}" ];
then  # compare if canonical name of both folders equal

Workaround is to remove the comments on those two lines (Anything after \).

Bumblebee – [ERROR]Cannot access secondary GPU – error: [XORG] (EE) Failed to load module „nvidia” (module does not exist, 0)

W sidzie napotkałem ostatnio na wywalenie się bumblebee mimo iż wszystko było wedle starej acz dobrej konifguracji, czyli moduły zbudowane:

    bbswitch, 0.8, 4.6.0-1-amd64, x86_64: installed
    bbswitch, 0.8, 4.8.0-1-amd64, x86_64: installed
    nvidia-current, 367.57, 4.6.0-1-amd64, x86_64: installed
    nvidia-current, 367.57, 4.8.0-1-amd64, x86_64: installed

Poprawnie skonfigurowany /etc/bumblebee.conf/bumblebee.conf.conf z:

Driver=nvidia
KernelDriver=nvidia-current

oraz /etc/bumblebee/xorg.conf.nvidia:

BusID "PCI:07:00:0"

A przy starcie krzyczał, że nie może sobie załadować modułu nvidia:

optirun --status
Bumblebee status: Ready (3.2.1). X inactive. Discrete video card is off.

optirun -vvv glxgears
[ 4067.950712] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
[ 4067.950993] [INFO]Configured driver: nvidia
[ 4067.951137] [DEBUG]optirun version 3.2.1 starting...
[ 4067.951146] [DEBUG]Active configuration:
[ 4067.951149] [DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[ 4067.951153] [DEBUG] X display: :8
[ 4067.951156] [DEBUG] LD_LIBRARY_PATH: /usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/nvidia
[ 4067.951160] [DEBUG] Socket path: /var/run/bumblebee.socket
[ 4067.951163] [DEBUG] Accel/display bridge: auto
[ 4067.951170] [DEBUG] VGL Compression: proxy
[ 4067.951176] [DEBUG] VGLrun extra options:
[ 4067.951180] [DEBUG] Primus LD Path: /usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus:/usr/lib/primus:/usr/lib32/primus
[ 4067.951224] [DEBUG]Using auto-detected bridge primus
[ 4068.128154] [INFO]Response: No - error: [XORG] (EE) Failed to load module "nvidia" (module does not exist, 0)

[ 4068.128165] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "nvidia" (module does not exist, 0)

[ 4068.128170] [DEBUG]Socket closed.
[ 4068.128185] [ERROR]Aborting because fallback start is disabled.
[ 4068.128187] [DEBUG]Killing all remaining processes.

lsmod|grep nvid
nvidia              11485184  0

Pomimo iż oczywiście się załadował. Po dłuższej dłubaninie i pytaniach w internetach doszedłem, że sterowniki z w tej wersji w sidzie jakieś niedorobione są i wystarczy zainstalować je z experimentala.

install -t experimental nvidia-driver

Po tym jak ręką odjął, wszystko działa 🙂

nixnote2 beta 5

Dawno brakowało mi jakiegoś klienta z gui do evernote na linuxie. Dopiero odnowiona/przepisana wersja nixnote na qt jako tako działa i wygląda.

Screenshot from 2015-12-08 18-04-48Jedyny problem to paczka która w zależnościach ma jakieś stare wersje libopenexr kiedy to w sidzie aktualna jest libopenexr6v5.

Dlatego też zapodaję poprawioną paczkę dla w/w wersji libopenexr: nixnote2-2.0-beta5_amd64.deb

debian – Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied

Taki sobie error pojawia się w przypadku próby dodania poprzez virt-managera. Dlaczego? Ano wiki debiana na którym się wzorowałem i pewnie nie tylko ja wspomina jedynie o dodaniu grup kvm i libvirt dla usera, nie wspomina jednak o ustawieniu dodatkowo w /etc/libvirtr/qemu.conf, np:

user = "pakos"
group = "pakos"

Po takim zabiegu wszystko powinno działać 😉

downgrade experminetal – unstable

Nie wiem dokładnie jak ja to wczoraj zrobiłem ale z normalną aktualizacją systemu połowa paczek zaciągła się z repo experimental. Czegoś takiego na co dzień nie chcę, wystarczą mi pojedyncze paczki. Ale jak to cofnąć? Niestety nie doszukałem się jakiejś zautomatyzowanej i prostej metody, jedynie manipulacja pinami.

w /etc/apt/preferences dodajem/edytujemy:

Package: *
Pin: release a=unstable
Pin-Priority: 1001

i apt-get upgrade, to powinno zainstalować paczki w wersji z sid’a. Nadal pozostaną jednak w systemie paczki z experimentala które zostały zainstalowane jako zależności a których w sidzie jeszcze nie ma.

Sprawdzamy co zostało:

aptitude search ~S~i~Aexperimental

i w zasadzie możemy je na tym etapie wywalić.

BOINC

Większość z naszych maszyn podczas gdy na nich nie pracujemy marnuje się (o ile są włączone oczywiście ;)) dlaczego by też nie wykorzystać ich w imię nauki.

W BOINC możemy wybrać sobie dowolny projekt dla którego udostępnimy swoją moc obliczeniową, wystarczy zainstalować:

aptitude install boinc-client

Graficznie resztę można wyklikać poprzez:

aptitude install boinc-manager

Gdy jednak maszyna nie posiada serwera graficznego możemy się posiłkować konfiguracją manualną (boinc-manager posiada opcję połączenia remote aczkolwiek nie mogłem w ten sposób dodać żadnego projektu, świetnie się jednak sprawdza później do podglądu jak nam idzie).

Tak więc wybieramy jakiś projekt, rejestrujemy konto na stronie i konfiguruejmy klienta:

boinccmd --lookup_account projekt mail haslo

np:

boinccmd --lookup_account http://setiathome.berkeley.edumail@mail haslo

pojawi się nasz kod, dodajemy go:

boinccmd --project_attach projekt kod

np:

boinccmd --project_attach http://setiathome.berkeley.edu kod

Aby móc połączyć się zdalnie w pliku /var/lib/boinc-client/remote_hosts.cfg podajemy ip a w /var/lib/boinc-client//var/lib/boinc-client hasło.

Na koniec w iptables otwieramy port 31416 i łączymy się managerem.

BOINC
BOINC

nagios monitorowanie procesu

W /etc/nagios/nrpe_local.cfg dodajemy:

command[check_*]=/usr/lib/nagios/plugins/check_procs -w 1: -c 1: -C proces

argumenty (-w 1: -c 1: -C) dopasowywujemy wedle woli, w tym przypadku ma być przynajmniej jeden proces.

Gdyby komenda /usr/lib/nagios/plugins/check_procs -w 1: -c 1: -C proces zwracała nieprawidłowy wynik trzeba sprawdzić jak nazwa procesu jest wyświetlana przez:

/bin/ps axwwo 'stat uid pid ppid vsz rss pcpu etime comm args' | grep proces

i odpowiednio zmodyfikować. Następnie edytujemy /etc/nagios3/conf.d/*_nagios2.cfg

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       localhost
        service_description             Check Transmission
                check_command                   check_nrpe_1arg!check_*
        }

i potem już tylko restart 😉

owncloud apache ssl

Ku pamięci.

aptitude install apache2 openssl
mkdir -p /etc/ssl/localcerts
openssl req -new -x509 -days 365 -nodes -out /etc/ssl/localcerts/apache.pem -keyout /etc/ssl/localcerts/apache.key
chmod 600 /etc/ssl/localcerts/apache*
a2enmod ssl

W /etc/apache2/sites-available/default-ssl dodajemy:

        <Directory /var/www/owncloud>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                Allow from all
                # add any possibly required additional directives here
                # e.g. the Satisfy directive (see below for details):
                Satisfy Any
        </Directory>

Na koniec:

 a2ensite default-ssl
 /etc/init.d/apache2 restart

I koniec 🙂

reinstalacja gruba luks

Był już kiedyś podobny temat ale teraz znowu męczyłem się z tym kilkanaście minut. Otóż obecnie /boot mam na osobnej partycji a sda5 zaszyfrowane. Standardowa metoda w sumie by się sprawdziła, z jednym szczegółem. Boot trzeba też zamontować ale nie jak to sugeruje rescue cd debiana, przed chrootem a właśnie po. Bez tego grub-install pluje errorami, że brakuje mu śmieci w /etc/default/grub, jednak po poprawnym podmontowaniu wszystko przechodzi bez zbędnych zmian. Czyli standardowo:

cryptsetup luksOpen /dev/sda5 sda5 (to akurat rescue cd robi za nas)
mount /dev/<vg>/<volume> /mnt/external
mount --bind /proc /mnt/external/proc
mount --bind /sys /mnt/external/sys
mount --bind /dev /mnt/external/dev
chroot /mnt/external
lvmdiskscan
vgchange -ay
lvscan
mount /dev/sda1 /boot
grub-install /dev/sda
update-grub

Oczywiście wszelkie nazwy dysków/lvm podajemy wedle własnej konfiguracji 🙂