Archiwum kategorii: Linux

Samsung SCX-3405W in Gentoo (Cups, drivers etc.)

TL;DR – emerge -va net-print/splix and use custom ppd file

Once upon a time my printer stopped working (of course when I want to print something urgently). The hardware was ok, working and not otherwise broken because connecting it to laptop did the job – I print urgent fliers.

What was weird, is that nothing was changed inside etc/cups directory. So there must be some other things that changed: /usr/libexec/cups was the natural choice. Specifically my ppd file included:

*cupsFilter: "application/vnd.cups-raster 0 rastertoqpdl"

And CUPS test page upon printing returned rastertoqpdl not available: No such file or directory. Well, this rastertoqpdl was supposed to be somewhere. Let’s look it up inside /usr/libexe/cups/filter. Nope – nothing, I’ve looked into backups half year back – nope, no such file. Ooo, let’s pick new driver maybe?

Unfortunately Samsung sold (??) it’s driver support to HP and they had a driver fresh and new for SCX-3400 family but it was not working –

Unable to open raster pipe raster stream - : Broken pipe

that’s what I got from every try to print anything. So driver was new (latest) but not functioning. It was not using rastertoqpdl filter though. Different route maybe? I downgraded cups, cups-filters, and checked with ldd proper binaries linking – nothing. But I know I had working setup with proper ppd file which contained rastertoqpdl. So where to get this file?

Ok, search the net – not much, search backup – none, older driver – same stuff. And after one day of fight (and sleep over with the problem) I stumbled upon 

[I] net-print/splix
Available versions: 2.0.0_p20130826 {+jbig}
Installed versions: 2.0.0_p20130826(16:48:17 01.09.2018)(jbig)
Homepage: http://splix.sourceforge.net/
Description: A set of CUPS printer drivers for SPL (Samsung Printer Language) printers

Yup, something for the Samsung from open source? My hope is almost depleted but I will emerge this and see what’s underneath. Woooaa, it has the rastertoqpdl which my working ppd is using. Come on, it can’t be. But it was – my printer was working again 🙂

BTW. Here’s my PPD file: https://gist.github.com/ChaosEngine/65532a1bb837e5adaa067af7670ff2c2

mplayer + youtube-dl = Super Combo

Z serii niesamowite jedno-linijkowsce

$ mplayer $(youtube-dl -g "<youtube link>")

na przykład:

$ mplayer $(youtube-dl -g "http://www.youtube.com/watch?v=EI7dJS02lzM")

Screen – moje zdalne autopodłączanie

Screen to jak wiadomo program do rozszerzania standardowego terminalu (lub emulatora terminala) o możliwość pracy na wielu ekranach. To uproszczenie ale przedstawia główną idee działania. Alternatywą do niego jest tmux, jednak ja raczej pozostaję wierny pierwowzorowi. Używam screena właściwie codziennie na komputerze lokalnie, na zdalnym serwerze i wewnątrz wirtualnej maszyny.

Przy zdalnym dostępie oczywiście wykorzystywany jest klient ssh. Dla jego wykorzystania zrobiłem sobie podręczny skrypt a właściwie funkcję basha automatyzującą podłączenie:

sshMyHost()
{
 ssh -L 8080:localhost:8080 -L 8081:remoteHost:8080 myUser@My.Host.com \
-t ". /etc/profile; screen -dR"
}

Taka funkcja standardowo łączy się przez ssh z hostem My.Host.com. Ciekawym natomiast jest opcja -t która powoduje automatyczne wywołanie podanego polecenia na zdalnej maszynie. I tu cały pic i magia; polecenie to

. /etc/profile; screen -dR

powoduje iż wczytywany jest główny profil login shella aby odświeżyć parametry locale, env itp. a następnie podłączamy się do istniejącej sesji screena lub tworzymy nową.

Ta funkcja, mimo iż prosta pozwala zaoszczędzić maaasę klikania i powtarzania machinalnych czynności. Często używane hosty są tak zdefiniowane do automatycznego szybkiego podłączenia. Oczywista, używam autoryzacji sesji SSH przy pomocy kluczy publicznych. Dążymy do tego aby jak najmniej niepotrzebnie klikać i obciążać naszą pamięć białkową 🙂 Funkcję tą doklejamy do ~/.bashrc albo ~/.bash_profile albo aby używać tego globalnie do /etc/bash/bashrc lub /etc/profile. Tym sposobem funkcja automatycznie się ładuje do zmiennych środowiskowych usera.
O obsłudze screena nie będę pisał bo każdy może znaleźć lepsze, obszerne manuale i tutoriale w sieci.

Skrypt backupowy

Jak mówi stare góralskie przysłowie: ludzie dzielą się na tych co robią backupy, i tych co je będą robić. Tym samym przedstawiam mój super prosty skrypt do backupowania systemu.

#!/bin/bash

ionice -c3 nice tar -cvpO \
  --exclude=/home/chaos/.VirtualBox/Machines \
  --exclude=/tmp/swap \
  --exclude=/home/pub \
  --exclude=/usr/portage \
  --exclude=/usr/src \
  --exclude=/var/log \
  --exclude=/var/tmp/distfiles \
  --exclude=/var/tmp/swap1 \
  /bin/ /boot/ /etc/ /home/ /lib/ /opt/ /sbin/ /usr/ /var/ \
| 7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on -p -si \
backup.tar.7z

Analiza zgodnie z kolejnością: odpalenie na niskim priorytecie I/O i procesora potoku tar-ującego do stdout. Zakładam paręnaście excludów na katalogi i podkatalogi których nie chcę backupować, definiuję katalogi główne do backupu. wyjście z tara kieruję na potok wejściowy pakera 7z który działa z maksymalną kompresją i szyfrowaniem wynikowego archiwum o nazwie backup.tar.7z. Używam tara bo tar zachowuje więcej parametrów plików niźli 7z by zrobił.
Z przeprowadzonych subiektywnych testów, 7z  pakuje z większym ratio niż gzip czy bzip, chociaż robi to dłużej.

DLNA vs Samsung LCD

Kontynuując wątek na temat sprzętu który posiadam lub konfigurowałem, teraz będzie o telewizorach. Dokładniej o telewizorach firmy Samsung. Jeden większy to Samsung LE40B650 a mniejszy to Samsung LE37C650. Jeden posiadają moi rodzice, drugi jest moją własnością. Oba sprzęty wpierają technologię DLNA/UPnP. Czyli najogólniej rzecz ujmując, potrafią odtwarzać zdalny kontent dostępny przez sieć LAN.

Na Linuksie najpopularniejsze rozwiązanie dla DLNA to użycie programu MediaTomb lub MiniDLNA. W sieci jest bardzo wiele tutoriali i opisów jak oba skonfigurować, szczególnie przy pomocy MediaTomba, więc nie ma sensu tego tutaj przytaczać.

Konfiguracja routera i Linuksa jest dość prosta – w dwóch routerach z jakimi miałem do czynienia wystarczyło włączyć opcję UPnP. Nie udało mi się  zmusić modelu Samsung LE40B650 do odtwarzania udostępnianych przez MediaTomba filmów, mimo zastosowania popularnego obejścia problemu. MiniDLNA mimo że jest prostszy, nie stroi żadnych fochów więc na nim ostatecznie się oparłem.

Oba telewizory bardzo dobrze odtwarzają udostępniane materiały różnych typów: zdjęcia, muzykę w formacie MP3, filmy wideo zakodowane w formacie MP4, AVI, DivX, Matroska itp. Jedyny problem powstał na Samsung LE40B650 przy odtwarzaniu filmów z dźwiękiem DTS. Sprzęt wyświetlał komunikat o braku wsparcia dla tego typu dźwięku. Podejrzewam że ten model nie ma albo zainstalowanego kodeka albo w ogóle mieć nie miał ze względu na brak licencji na DTS.

Problem z dźwiękiem obszedłem trochę siłowo, mianowicie każdy taki film z dźwiękiem DTS rozdzielam na dwa strumienie: dźwięk i obraz. Używam do tego pakietu mkvtoolnix. Następnie plik z wyodrębnionym dźwiękiem DTS konwertuję na format AC3 przy pomocy ffmpeg i całość łączę znowu przy użyciu mkvtoolnixa. Opcjonalnie można jeszcze wykonać „hardsubbing” napisów do strumienia wideo, ale ten proces jest bardzo pracochłonny – na słabym procesorze film 4GB potrafi się konwertować od paru godzin do pół dnia :-). Konwersję taką wykonuję przy użyciu mencoder-a.

Po reorganizacji sprzętów i mebli padło na to, iż telewizor u rodziców oddali się od routera na tyle znacznie, iż nie opłaca się ciągnąć do niego kabla ethernet. Dlatego niejako zmuszony zostałem do kupna adaptera WiFi przystosowanego do obsługi sieci WiFi dla telewizorów Samsunga. Urządzenie mimo iż niepozorne spisuje się bardzo dobrze.

Podsumowując, można powiedzieć iż telewizory Samsunga odznaczają się ponadprzeciętnymi właściwościami multimedialnymi i w połączeniu z Linuksem (i nie tylko) potrafią zapewnić sporo rozrywki i zabawy 🙂

Skrypty:

#Konwersja dźwięku z filmu do pliku AC3
ffmpeg -i orginalnyPlikZFilmem.mkv -vol 750 -threads 4 -acodec ac3 -ac 6 -ab 448k wyjsciowyPlikAudioAC3.ac3

#Łączenie dźwięku AC3 ze strumieniem wideo. Wynikiem jest nowy plik MKV
mkvmerge -o docelowyPlikWynikowyZeZlaczanymDZwiekiemAC3iObrazem.mkv \
"--language" "1:eng" "--default-track" "1:yes" "--forced-track" "1:no" \
"--display-dimensions" "1:1280x528" "--default-duration" "1:23.976fps" \
"--compression" "1:none" "-d" "1" "-A" "-S" "-T" "--no-global-tags" \
"--no-chapters" "orginalnyPlkikZFilmem.mkv" "--language" "0:pol" "--forced-track" \
"0:no" "--compression" "0:none" "-a" "0" "-D" "-S" "-T" "--no-global-tags" \
"--no-chapters" "plikZeSkonwertowanymDzwiekiemAC3.ac3" "--track-order" \
"0:1,1:0"

#Wgrywanie (hardsubbing) napisów do filmu
mencoder orginalnyPlikZFilmem.mkv -o wyjsciowyStrumienWideoZWgranymiNapisami.h264 \
-nosound -ovc x264
-sub plikZNapisamiDoFilmu.txt -subcp cp125 \
-x264encopts bframes=3:weight_b:partitions=all:8x8dct:subq=5:frameref=2:bitrate=7000

Nagrywanie pulpitu

Od dłuższego czasu wykorzystuję ffmpeg do konwersji filmów, dźwięku i wszelkiej maści mediów cyfrowych. Przed paroma dniami natknąłem  się na niesamowite zastosowanie jakim jest zgrywanie pełnoekranowego pulpitu pod X-ami. Otóż wykonuje się je na przykład tak:

ffmpeg -f x11grab -s 1600x900 -i :0.0+,224 -acodec mp3 -ac 1 -vcodec libx264 -threads 4 -f matroska capture.mkv

nie dość że obraz jest w wybranej rozdzielczości (tu 1600×900) to jeszcze stosujemy kompresję H264 i pakujemy wszystko do formatu Matroska
Dla mnie bomba!

Aktualizacja: Nowsza wersja łapiąca oprócz obrazu również dźwięk. Jest mały problem z brakiem synchronizacji ale ogólne wrażenie nadal świetne:

#!/bin/bash
#
NAME=$(basename $0)
SNDFILE=$(mktemp /tmp/$NAME.XXXXXX) || exit 1

arecord -f S16_LE -c1 -r44100 -t wav $SNDFILE &amp;amp;amp;amp; PIDaudio=$!

ffmpeg -y -i $SNDFILE -f x11grab -s 1600x900 -r 25 -i :0.0+,224 -vcodec libx264 -threads 0 -f matroska -acodec ac3 "$1" &amp;amp;amp;amp; PIDvideo=$!

read -p "Press enter to stop recording"
kill $PIDvideo $PIDaudio
rm -f $SNDFILE

Monitorowanie web-cam’em

Dawno dawno temu w odległej galaktyce… kupiłem kamerkę 😉

Była to VF0420 Live! Cam Vista IM
Szybko znudziła mi się jako zabawka do „pogaduch sieciowych” i postanowiłem zrobić z niej użytek do monitorowania obiektu czy też posesji.
Dlatego też, wystawiłem ją przez okno aby obserwowała wejście na teren działki, podpiąłem pod maszynę Linuksową (Gentoo).

Użyłem „kernelowych” sterowników gspca(model ov519) oraz zainstalowałem soft do robienia zrzutów, MJPG-Streamer.
MJPG-Streamer udostępnia stream w formacie MJPG (który na dobrą sprawę generuje sama kamera) z bardzo małym narzutem na CPU.
Oprócz streamu można też łapać pojedyncze klatki obrazu JPG co właśnie najbardziej mnie interesowało.
Skrypt bash podpięty do cron’a co 10 minut pobiera klatkę obrazu z kamerki i wrzuca ją do katalogu przy użyciu mechanizmu rotacyjnego.
Inny skrypt PHP przeszukuje katalog i wyświetla wszystkie obrazy JPG pasujące do wzorca nazwy w formacie tabelki obrazków. Dodatkowo codziennie o 22:00 inny skrypt używając mencoder’a łączy te JPG-i i tworzy wideo, niejako tworząc przyspieszony obraz wydarzeń z całego dnia rejestrowania kamery.

Skrypt wyciągający JPG-i z deamona MJPG-streamer:

#!/bin/bash

#gets image from webcam served and saves it into first param
function shot()
{
        /usr/bin/curl "http://localhost:3000/?action=snapshot" -o $1 2>/dev/null;
}

#check if webcam server(mjpg-stream) is running; quit if not
pgrep mjpg_streamer 1>/dev/null; [ $? != 0 ] &amp;&amp; exit 1;

#maximum number of pictures to take, if exceed - start from 0
pic_num=144;
#where the pics are stored
cd /var/www/localhost/htdocs/webcamgallery/
#set permissions accordingly
umask -S o+r 1>/dev/null;

#set current picture name accordingly
line=`/bin/ls *current* 2>/dev/null | /usr/bin/gawk 'BEGIN { FS="-";} /current/ { printf("%s %i out-current-%i-.jpg out-%i.jpg out-%i.jpg", $0, $3, ($3 + 1) > '$pic_num' ? 0 : ($3 + 1), $3, ($3 + 1) > '$pic_num' ? 0 : ($3 + 1) ); }' -`;

#make screenshot
if [ "$line" == "" ]; then
        #echo bummer!
        shot "out-current-0-.jpg";
fi

#format variables
set -- ${line#*:}; current=$1 num=$2 new_current=$3 old_current=$4 kwas=$5;

#move current image to old current and new pic shot to current
mv -f $current $old_current 2>/dev/null;
mv -f $kwas $new_current 2>/dev/null;

shot $new_current;

To natomiast jest skrypt robiący film(y) z obrazków JPG:

#!/bin/bash

#go to images location
cd /var/www/localhost/htdocs/webcamgallery;
j=0;

#make poster from 1st image and change other out*jpg images names to new*.jpg
for file in `ls -tr out*jpg`; do
if [ "$j" == "0" ]; then
/bin/cp -f $file poster.jpeg;
fi
/bin/cp -f $file `printf "new-%03d.jpg" $j`; j=$((j+1));
done;

#make WebM video from new* images
mencoder mf://new*.jpg -mf w=640:h=480:fps=15:type=jpg -really-quiet -nosound -ovc lavc -ffourcc VP80 -of lavf -lavfopts format=webm -lavcopts vcodec=libvpx -o video.webm

#make video.mp4 video fro flash from new*images
ffmpeg -y -i new-%03d.jpg -vcodec libx264 -level 41 -crf 25 -bufsize 20000k -maxrate 25000k -g 250 -r 20 -s 640x480 -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -bf 16 -b_strategy 1 -bidir_refine 1 -refs 6 -deblockalpha 0 -deblockbeta 0 -v 0 -loglevel quiet video.mp4 2&amp;amp;amp;amp;gt; /dev/null

#set permissions
chmod 644 video.webm video.mp4 poster.jpeg
#remove unneccessary new images - cleanup
rm -f new*jpg

Dodatkowo jest jeszcze trochę kodu PHP który wyświetla zrzuty JPGów z całego dnia w tabelaryczny i uporządkowany sposób ale nie ma sensu tego pokazywać.

Końcowy efekt można podziwiać tu: http://haos.hopto.org/webcamgallery/

H4ck

Ostatnio zainteresowałem się tematem bezpieczeństwa (i nie-) w sieciach bezprzewodowych. Nie chcę powtarzać oczywistości jak to że WEP jest „be” a WPA w dobrej konfiguracji ok. Bardziej mnie zainteresowało łamanie mocnych zabezpieczeń w nietrywialnych konfiguracjach.

Jak dojdę do własnych konkretnych konkluzji to pewnie je tu opiszę; na razie testy są w trakcie realizacji

Gentoo na laptopie

No i stało się, zainstalowałem Gentoo na laptopie 🙂
Wcześniejsze Ubuntu było fajne, działało nieźle, wyglądało super, zero wysiłku itp. ale czegoś mi jednak brakowało. Brakowało mi portage, gentoolkit, znanego mi zarządzania pakietami specyficznego podejścia filozoficznego Gentoo.

Oczywiście doprowadzenie do podobnie działającego systemu jest o niebo dłuższa w przypadku Gentoo, jednak jest bardziej świadoma, dostarcza o wiele więcej frajdy (no może jak dla kogo) i jest o wiele bardziej pouczająca ;-P

Przejście z ~x86 na x86

W Gentoo, a właściwie w portage istnieje możliwość instalowania pakietów stabilnych i niestabilnych. Rozróżnienie dokonywane jest poprzez zmienną środowiskową ACCEPT_KEYWORDS. Większość pakietów jest w dwóch wersjach: stabilnej i niestabilnej. Oficjalny podręcznik zaleca używanie stabilnej gałęzi portage poprzez ustawienie ACCEPT_KEYWORDS="arch" (gdzie arch to architektura systemu: x86, amd64, sparc itp.). Ustawienie arch jest bezpieczniejsze oraz mniej destabilizujące system. Zaletami niestabilnego systemu są najświeższe wersje pakietów, posiadające najnowsze funkcjonalności, „ficzersy” itp. Podręcznik opisuje sposób jak mieszać stabilne i niestabilne wersje pakietów. Nie wdając się w szczegóły robi się to przy pomocy /etc/portage/package.keywords.

Do niedawna mój system cały oparty był o niestabilne drzewo ~x86. Niestety wiele razy byłem z tego niezadowolony: kolidujące zależności, błędnie działające systemowe biblioteki i konfiguracje były nieraz na porządku dziennym. Wiele razy dochodziłem do tego iż zbyt częste aktualizacje nie wprowadzają nic dobrego. W końcu powiedziałem sobie dość, przechodzę na stabilne x86. Zmieniłem ACCEPT_KEYWORDS na x86 i zadałem emege -ve world. Oczywiście nie było za różowo i parę razy musiałem odpalać revdep-rebuild (porządkując zależności bibliotek) ale generalnie „zdowngradowałem” cale zatrzęsienie pakietów zachowując dobrze działający system. Postanowiłem iż odtąd będę cały system (emerge system) i niskopoziomowe biblioteki i pakiety instalował/aktualizował tylko z x86 a pozostałe,wybrane mniej krytyczne pakiety pozwalał wybiórczo zaciągać z ~x86.

Przy przechodzeniu na stabilny arch nie mogłem cofnąć bez obawy sys-libs/glibc, jako że jest to zależność która jest wymagana właściwie przez wszystko w systemie. Pozostało mi  czekać na ustabilizowanie się mojej obecnej wersji glibca. Dodatkowo, z uwagi na to iż mam parę urządzeń które obsługiwane są tylko przez overlay-owe albo niestabilne sterowniki musiałem zezwolić na parę takich „perełek”.