my personal page

Dostrajanie serwerów baz danych to sprawa wyjątkowo skomplikowana. Zostało na ten temat napisanych wiele książek, niejeden „spec” poświęcił niejedną godzinę, żeby to ustrojstwo chodziło wydajnie i gładko. Zadanie wymaga naprawdę wielkiej wiedzy i sporego doświadczenia, co jest – szczególnie w obecnych czasach – dość kosztownym zasobem.

Ale co w przypadku, kiedy nasz serwer dostaje czkawki, nie mamy na koncie wystarczających środków, żeby zatrudnić specjalistę, a musimy coś zrobić? Jest taki fajny skrypcik napisany w PERLu, który umożliwia (bardzo) wstępną diagnozę w stylu „co mogę zrobić, żeby działało lepiej”. Nie poda nam wprawdzie przepisu na usprawnienie wszystkiego i nie spowoduje, że MySQL zacznie odpowiadać 10x szybciej, ale wskaże nam, gdzie możemy poszukać i skąd wyciągnąć jeszcze odrobinę mocy.

Skrypt ten magiczny to mysqltuner i działa o tak:

[kbechler@ns ~]$ ~/mysqltuner.pl

 >>  MySQLTuner 1.2.0 - Major Hayden 
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: 
Please enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.77
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 3G (Tables: 48163)
[--] Data in InnoDB tables: 129M (Tables: 185)
[--] Data in MEMORY tables: 0B (Tables: 6)
[!!] Total fragmented tables: 120

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 61d 3h 39m 32s (472M q [89.360 qps], 31M conn, TX: 2707B, RX: 63B)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 282.0M global + 2.7M per thread (250 max threads)
[OK] Maximum possible memory usage: 969.5M (12% of installed RAM)
[OK] Slow queries: 0% (684/472M)
[OK] Highest usage of available connections: 60% (152/250)
[!!] Key buffer size / total MyISAM indexes: 8.0M/313.6M
[!!] Key buffer hit rate: 92.3% (6B cached / 491M reads)
[OK] Query cache efficiency: 36.4% (131M cached / 362M selects)
[!!] Query cache prunes per day: 2758813
[OK] Sorts requiring temporary tables: 0% (132K temp sorts / 18M sorts)
[!!] Joins performed without indexes: 217457
[!!] Temporary tables created on disk: 44% (44M on disk / 99M total)
[OK] Thread cache hit rate: 93% (2M created / 31M connections)
[!!] Table cache hit rate: 0% (2K open / 4M opened)
[!!] Open file limit used: 89% (3K/4K)
[OK] Table locks acquired immediately: 99% (256M immediate / 256M locks)
[!!] Connections aborted: 28%
[!!] InnoDB data size / buffer pool: 129.8M/64.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Increase table_cache gradually to avoid file descriptor limits
    Your applications are not closing MySQL connections properly
Variables to adjust:
    key_buffer_size (> 313.6M)
    query_cache_size (> 16M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    tmp_table_size (> 192M)
    max_heap_table_size (> 256M)
    table_cache (> 2048)
    open_files_limit (> 4356)
    innodb_buffer_pool_size (>= 129M)

Teoretycznie powinienem postąpić zgodnie z powyższymi sugestiami i pozwiększać różne parametry do podanych tam poziomów. Ale w praktyce warto zmienić jeden (no, może dwa) parametr i popatrzeć, czy maszyna zaczęła się zachowywać choć trochę lepiej. Patrzenie mozna uprawiać np. przy pomocy Cacti i szablonów, które niedawno opisywałem.

A tak zupełnie przy okazji – jakiś czas temu natrafiłem na świetny blog (hmmm, „świetnego bloga?”) na temat MySQLa właśnie. Znajduje się pod adresem blog.ksiazek.info, prowadzi go Krzysztof Książek i zdecydowanie warto tam zaglądać regularnie.

Tym razem wpis z gatunku tips-and-tricks.

Dostałem w pliku listę pakietów, które miałem zainstalować w nowym systemie. Niestety, plik wyglądał mniej-więcej tak:

[kbechler@flame tmp]$ cat ./packages.txt
binutils-2.17.50.0.6
compat-libstdc++-33-3.2.3
compat-libstdc++-33-3.2.3 (32 bit)
elfutils-libelf-0.125
elfutils-libelf-devel-0.125
gcc-4.1.2
gcc-c++-4.1.2
glibc-2.5-24
glibc-2.5-24 (32 bit)
glibc-common-2.5
glibc-devel-2.5
glibc-devel-2.5 (32 bit)
glibc-headers-2.5
ksh-20060214
libaio-0.3.106
libaio-0.3.106 (32 bit)
libaio-devel-0.3.106
libaio-devel-0.3.106 (32 bit)
libgcc-4.1.2
libgcc-4.1.2 (32 bit)
libstdc++-4.1.2
libstdc++-4.1.2 (32 bit)
libstdc++-devel 4.1.2
make-3.81
sysstat-7.0.2

[kbechler@flame tmp]$

Wrzucenie tego bezpośrednio do YUMa teoretycznie powinno zadziałać, ale jest mało eleganckie, bo:

• Ciąg znaków „(32bit)” nie zostanie rozpoznany jako poprawna nazwa pakietu, więc YUM będzie marudził, że nie znalazł wszystkiego, o co został poproszony,

• Pakiety od chwili publikacji listy, którą dostałem, mogły zostać zaktualizowane i – żeby mieć pewność, że zainstalowałem ich najnowszej wersje – powinienem po instalacji jeszcze raz puścić YUMa z opcją „update”.

Pierwsze zadanie (które jest bohaterem niniejszego wpisu) to: jak przerobić listę pakietów tak, żeby usunąć z niej zbędne elementy w postaci informacji o ilości bitów oraz aktualnej wersji pakietu. Innymi słowy – jak pozbyć się znaków, które występują po ostatnim myślniku :-)

Najpierw przyszło mi do głowy nieśmiertelne i bardzo często przeze mnie używane polecenie cut. Niestety, po przejrzeniu manuala okazało się, że nie umie zrobić tego, co bym chciał, bo potrafi liczyć tylko od początku (ja potrzebuję liczyć od końca, bo ilość „elementów” w wierszach jest różna).

Przyszła kolej na AWKa. Nie udało mi się wprawdzie znaleźć problemu, którego by się nie dało AWKiem rozwiązać, ale wyszło mi coś, co nie wygląda zbyt zrozumiale:

awk -F'-' '{for(i=1;i
I w tym momencie przypomniało mi się, że w Linuksie (hmmm, w innych systemach Uniksowych pewnie też) jest magiczna komenda rev, która odwraca ciąg znaków. Z połączenia tego (mało znanego) "narzędzia" oraz (zdecydowanie lepiej znanego) cut'a udało mi się zrobić coś takiego:
cat ./packages.txt | rev | cut -d- -f2- | rev
Żeby było już tak zupełnie poprawnie, to warto usunąć duplikaty:
cat ./packages.txt | rev | cut -d- -f2- | rev | sort | uniq
Pozostaje ostatnie pytanie: Jak to "wrzucić" do YUMa?

Ano nic prostszego:
sudo yum install `cat ./packages.txt | rev | cut -d- -f2- | rev | sort | uniq`
Metoda jest na pewno dość powolna i na pewno za pomocą AWKa, PERLa czy czegoś podobnego, dałoby się zrobić to bardziej wydajnie, jednak do jednorazowego przerobienia kilkuset linii jest zdecydowanie najprostsza do napisania i najbardziej czytelna.
Ostatecznie: Jeżeli chcemy usunąć część ciągu znaków i musimy liczyć od końca, to najłatwiej jest taki ciąg odwrócić, użyć cut'a i odwrócić jeszcze raz. O tak:
 ... | rev | cut -d- -f2- | rev

Firma, jak firma. Używamy różnego oprogramowania, czasami bardzo nowoczesnego, a czasami „trochę starszego”. Czasami są to rozwiązania tak standardowe, że aż nudne, a czasami tak magiczne, że nie bardzo wiadomo, co z nimi zrobić – szczególnie, jak się popsują. Na moje nieszczęście w kilku miejscach działają konfiguracje jednocześnie stare (ze względu na zastosowane w nich rozwiązania) i magiczne, od których każdy stara się trzymać z daleka. Do tej pory szło nam nawet nieźle, aż tu nagle niespodzianka w postaci nowej wersji starego produktu. „Docelowo będzie to rozwiązane inaczej, ale teraz klient wymaga, więc musimy uruchomić tak, jak jest”. OK, nas klient nas Pan, ale trafiłem na drobną przeszkodę – do działania potrzebny jest tytułowy mimencode. Zgodnie z dokumentacją, „By default, mimencode reads standard input, and sends a 'base64′ encoded version of the input to standard output.” Hmmm, niby można to zrobić np. w PERLu za pomocą kliku linijek, ale producent się uparł, że ma być binarka i już.

Kiedyś program ten dostępny był w pakiecie „metamail”, ale – z niewiadomych mi przyczyn – pakietu już nie produkują. Na początku przyszedł mi do głowy pomysł skompilowania tego cudaka ze źródeł. Ale nie jest to rozwiązanie optymalne, bo akurat nie miałem pod ręką żadnego systemu z odpowiednim kompilatorem i wszystkimi wymaganymi biliotekami, a instalowanie tego wszystkiego było ponad moje siły. Szczególnie, że to przecież „tylko na chwilę”.

Spróbowałem trochę inaczej: skoro kiedyś metamail był dostępny, to dlaczego nie wykorzystać paczki z jakieś starej wersji RedHata (z czasów, kiedy był jeszcze darmowy). Mój wybór – zupełnie przypadkowo – padł na wersję 2.7.28 (a konkretnie na TĄ paczkę). Instalowanie takiego dinozaura w systemie nie wydaje mi się najszczęśliwszym posunięcięm, ale przecież RPMy to tak właściwie archiwa z plikami i kilka skryptów, więc wypakowałem sobie potrzebny mi program do /usr/local/bin i sprawdziłem, czego tak właściwie wymaga:

[kbechler@kali ~]$ ldd /usr/local/bin/mimencode
        linux-gate.so.1 =>  (0xf770c000)
        libc.so.6 => /lib/libc.so.6 (0xf757a000)
        /lib/ld-linux.so.2 (0xf770d000)
[kbechler@kali ~]$

Jak widać, prawie niczego. Zadziałało, więc niech sobie „na chwilę” zostanie…

Administracja jednym serwerem to przyjemność. Administracja setką, to poważna praca. Która na dodatek staje się bardzo uciążliwa, jeżeli systemy są różne, a my nie mamy narzędzia do monitorowania naszego środowiska. Metod podglądania szeroko pojętych zasobów IT jest bardzo dużo. Od prostego w obsłudze MRTG i kilku domowej roboty skryptów, do „kombajnów” umożliwiających obejrzenie każdej śrubki w naszej serwerowni. Zestawienie tego typu narzędzi dostępne jest na przykład tutaj. Ja najczęściej używam duetu Nagios+Cacti. Nie dlatego, że jest najlepszy ze wszystkich, ale dlatego, że te programy znam i ich obsługa jest dla mnie wystarczająca wygodna, aby nie szukać niczego nowego. Tak właściwie to tutaj powinienem się przyznać, że należę do grupy ludzi raczej leniwych i bardzo dawno nie próbowałem używać czegokolwiek innego, więc być może korzystam z narzędzi, które powinny zostać zapomniane i wyparte przez inne – bardziej nowoczesne/nowatorskie – rozwiązania. Dobra, ale ja tak właściwie nie o tym, więc przejdźmy do tematu głównego.

Jeden z serwerów, którymi się opiekuję zaczął mieć problemy wydajnościowe. Tak naprawdę, to ma je „od zawsze”, ale klient nie daje się namówić na zmiany. Zawsze znajdzie jakąś wymówkę i twierdzi, że „niedługo będziemy to wszystko przebudowywać, więc na razie szkoda czasu”. Trwa to już od kilku miesięcy, ale co ja mogę? Jedyne, co mi przyszło do głowy, to zacząć robić statystyki, żeby ów klient mógł sobie obejrzeć (jeden niepozornie wyglądający obrazek potrafi czasami zdziałać cuda) jak bardzo jest źle i dlaczego ja w ogóle marudzę. Obciążenie systemu (load average) oraz wykorzystanie pamięci są wskaźnikami zbyt abstrakcyjnymi dla webmasterów i ich szefów, więc nie tędy droga. Zacząłem więc szukać szablonów do kaktusa, które umożliwią stworzenie dzieł sztuki (mylnie nazywanych wykresami) obrazujących rzeczywiste zaangażowanie serwera przy spełnianiu żądań (często politycznie nazywanych „życzeniami”) klientów.

Zacząłem więc buszować po forum Cacti i natknąłem się na kilka mniej lub bardziej udanych szablonów, jednak żaden z nich mnie jakoś specjalnie nie zachwycił. Owszem, większość z nich działała poprawnie, ale wszystkie sprawiały wrażenie (piszę o moich subiektywnych odczuciach, więc pewnie są to produkty na miarę jakiejś wyrafinowanej nagrody, a ja się zwyczajnie nie znam) oderwanych od całości. Spróbowałem inaczej, wpisałem w googla co ja tak naprawdę chciałbym monitorować i trafiłem na stronę poświęconą projektowi Percona Monitoring Plugins. Okazało się, że był to strzał w dziesiątkę, bo w jednym miejscu znalazłem szablony dla MySQLa, Apache’a oraz kilka fajnych rzeczy dla Linuksa. Wszystko okraszone świetną dokumentacją (jest nawet procedura instalacji typu „krok po kroku” oraz krótki opis, co który wykres obrazuje). Panowie (a być może i panie – nie wiem) z Percony – jak zwykle z resztą – wydali produkt dopracowany, z kompletną i jasną dokumentacją, który bardzo ułatwia pracę i sprawia, że życie zawodowe stało się odrobinę bardziej znośne :-)

Spsób, w jaki działają szablony nie jest jakiś specjalnie odkrywczy, ale bardzo miłe jest to, że wszystkie korzystają z tych samych mechanizmów:

• skrypt PHP, który łączy się bezpośrednie z serwerem MySQL na zdalnej maszynie,
• „SSH-based templates”, czyli inny skrypt PHP, który pobiera dane z monitorowanych maszyn za pomocą połączenia SSH. W dokumentacji jest nawet ładnie opisane, jak wygenerować odpowiedni zestaw kluczy i wszystko razem skofigurować tak, żeby działało.

Po 15 minutach konfiguracji udało mi się uruchomić monitoring najważniejszych elementów systemu, co uważam za bardzo dobry rezultat. Szczególnie, jeżeli weźmiemy pod uwagę stosunek poświęconego czasu do korzyści wynikających z posiadania takich danych, jak „apache requests” czy rozbicie wykonanych przez bazę SELECTów na poszczególne ich typy.

Hmmm, ten wpis wygląda chyba trochę jak średniej jakości case-study z folderu reklamowego, ale to wszystko naprawdę działa tak, jak powinno :-)

Mam pod opieką serwer, który generuje bardzo duże ilości logów. Nie byłoby w tym nic strasznego, gdyby nie to, że dosyć często trzeba do tych logów zaglądać, bo – jak to w logach – znajdują się tam cenne dla nas informacje. Jeszcze gorzej, że do tych informacji muszą mieć dostęp nie tylko administratorzy, ale także pracownicy helpdesku, dla których grep i potoki w konsoli linuksowej nie są specjalnie przyjazne i intuicyjne. Na szczęście w miarę prosto można zmienić konfigurację syslog’a w CentOSie tak, żeby (obok pliku) zapisywał logi do bazy danych. Jeżeli mamy działający serwer MySQL, to cała procedura zamyka się w utworzeniu odpowiedniej bazy na serwerze (nie zapomnijmy o odpowiednich prawach dostępu!) oraz zmianie pliku konfiguracyjnego /etc/rsyslog.conf. Fajny dokument opisujący jak skonfigurować rsysloga do pracy z MySQLem można znaleźć TUTAJ (warto od razu przeczytać także TO).

Wszystko pięknie, tylko nasz bohater generuje kilkaset tysięcy wpisów dziennie, wobec czego w bardzo niedługim czasie baza przestałaby być używalna, bo przeszukiwanie jej zajmowałoby strasznie dużo czasu. Niezupełnie o to nam chodzi. Szczególnie, że użyteczne dla nas są jedynie te wpisy, które zostały utworzone w ciągu ostatniego tygodnia (starsze i tak są archiwizowane w postaci „standardowych” plików sysloga, a potrzeba dostępu do nich zdarza się niezmiernie rzadko).

I tutaj z pomocą przychodzi cron i taki oto króciutki skrypcik:

#!/bin/bash
echo "DELETE FROM SystemEvents WHERE DATE_SUB(CURDATE(), INTERVAL 7 DAY) >= DeviceReportedTime;" | mysql -h db_host -u db_user --password=db_pass Syslog

Zrobiłem dowiązanie symboliczne do tego pliku w katalogu /etc/cron.daily i mogę zająć się innym problemem :-)

Dzisiaj będzie o poczcie, tej elektronicznej oczywiście.

Od pewnego czasu zmagamy się z rosnącą ilością SPAMu, który próbuje zawładnąć naszymi skrzynkami mailowymi i zeżreć całą przestrzeń dyskową na serwerach pocztowych. Jeszcze nie tak dawno wystarczyły proste (w konfiguracji, nie z racji zasady działania) filtry Bayesa i kilka RBLi, żeby zapewnić użytkownikom w miarę spokojną pracę. Obecnie, nawet po przejrzeniu wszystkich ustawień serwerów pocztowych i zmianie polityki na bardziej rygorystyczną, ilość śmieci trafiająca do skrzynek jest co najmniej nieakceptowalna. Jak z tym walczyć?

Pierwszym krokiem było odizolowanie serwerów pocztowych bezpośrednio obsługujących użytkowników od Internetu za pomogą bramy (na której działa pierwsza linia walki z niechcianymi wiadomościami). Ponieważ filtry były skonfigurowane bardzo podobnie do wcześniej przez nas używanych, nie osiągnęliśmy prawie żadnej poprawy. Poza jedną rzeczą. Ubocznym skutkiem jest zmniejszenie obciążenia serwerów mailowych, bo nie muszą już użerać się z tonami SPAMu, który jest odsiewany na bramie.

Drugim krokiem było skonfigurowanie nowego systemu tak, aby jak najwcześniej pozbywał się maili, które wyglądają bardzo podejrzanie. I tak – jedną z podstawowych rzeczy, którą włączyłem było odrzucanie wiadomości z serwerów, które niepoprawnie się przedstawiają(*).

Natknęliśmy się jednak na dość poważny problem – kilka serwerów pocztowych należących do naszych klientów okazało się być skonfigurowanymi dość… osobliwie. I tu przychodzi tytułowe naprawianie świata, bo nie poddaliśmy się od razu i powysyłaliśmy do administratorów tych systemów prośby o zmianę konfiguracji (na poprawną). Zadziałało, kilka serwerów pocztowych w Internecie zaczęło przedstawiać się zgodnie z RFC 2821.

Przy okazji – jeżeli ktoś szuka informacji, jak skonfigurować działający, bezpieczny i elastyczny serwer pocztowy oparty na Postfiksie, to dwiema żelaznymi pozycjami do poczytania są:

• Dokumentacja postfixa (w szczególności TEN dokument),
• Strona Lemata (a konkretnie TO).

(*) Chodzi o parametry reject_invalid_helo_hostname, reject_unknown_helo_hostname oraz reject_non_fqdn_helo_hostname w konfiguracji Postfixa, które odrzucają wiadomość, jeżeli serwer wysyła niepoprawną nazwę hosta po HELO.

Zdarza się tak, że potrzebujemy dostępu do hosta w odległej sieci, a do dyspozycji mamy jedynie dostęp do Internetu, gdzie – jak wiadomo – czają się przestępcy. Naturalnym rozwiązaniem jest zestawienie bezpiecznego połączenia (VPN) ze zdalną siecią i za jej pomocą dostanie się do pożądanych zasobów. Co jednak w przypadku małej sieci, do której nikt nigdy zdalnie się nie łączy i w której nie ma skonfigurowanej usługi VPN, której moglibyśmy użyć? Jeżeli wystarczy nam kilka portów TCP i mamy po drugiej stronie SSH „wystające” na świat, to możemy użyć Putty.

Zadanie jest następujące: dostać się za pomocą protokołu RDP (port tcp/3389) do maszyny o adresie 192.168.0.2. Host, do którego będziemy ustanawiać sesję SSH musi oczywiście wiedzieć, co to jest 192.168.0.2 i mieć dostęp do odpowiedniego portu.

1. Uruchamiamy PUTTY i wpisujemy nazwę domenową (lub adres IP) hosta, który rozumie SSH:

2. Przechodzimy do zakładki „Connection -> SSH – > Tunnels” i wypełniamy odpowiednie pola:
„Source port” to port TCP po stronie naszego lokalnego komputera, który „zmapujemy” na zdalną maszynę
„Destination” to adres i numer portu TCP zdalnego systemu

Potem wciskamy guzik „Add”. Możemy oczywiście dodać więcej portów (niekoniecznie do tego samego hosta).

Na koniec wciskamy „Open”, uwierzytelniamy się po SSH i możemy łączyć się ze zdalnymi zasobami używając adresu loopback (127.0.0.1) i odpowiednich portów.

Jakiś czas temu pisałem o ustawianiu kodowania dla sesji terminalowych w programie putty. Udało mi się wtedy wykombinować metodę, za pomocą której uzyskałem ładne ramki w Midnight Commanderze oraz wparcie dla UTF-8. Tylko nie napisałem jednej, dość ważnej rzeczy – jak zmienić ustawienia domyśle putty tak, żeby nie trzeba było za każdym razem mozolnie wybierać odpowiednich opcji.

Okazuje się, że zmiana domyślnych wartości parametrów jest wyjątkowo trywialna. Oto, co należy zrobić:
1. Otworzyć nowe okno putty,
2. Wybrać „Default Settings” z okna zapisanych sesji i wcisnąć „Load”,
3. Poustawiać sobie opcje według uznania (np. zmienić domyślne kodowanie na UTF-8 i „podrasować” kolorki),
4. Wrócić do „głównego” okna programu, czyli zakładki „Session”,
5. Pilnując, aby „Default Settings” było ciągle aktywną opcją, wcisnąć „Save”.

I tyle. Dzięki temu, w rejestrze Windows w gałęzi HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions zostanie utworzona nowa struktura opisująca domyślne parametry, które putty będzie od tej pory wczytywało od razy po uruchomieniu. Niby proste, ale na tyle nieuntuicyjne (przynajmniej dla mnie), że postanowiłem to opisać.

[dzisiaj będzie odrobina narzekania]

Mam router łączący sieć lokalną w pewnym budynku ze światem. Prosty routing, kilka ACLek, NAT, niby nic ciekawego. Ale zachciało mi się podłączyć to urządzenie do Cacti celem stałego monitorowania działalności użytkowników. O ile wykresy dotyczące obciążenia procesora oraz ilości przepływających przez interfejsy danych udało mi się wyklikać w ciągu minuty, to na badaniu ilości bieżących translacji poległem. Wymęczyłem dość porządnie wujka Google i udało mi się dowiedzieć jedynie tyle, że inni także mają taki problem. Niby znalazłem template do kaktusa, który robi dokładnie to, czego mi potrzeba, jednak mój router (Cisco 1811) uparcie wyrzuca na użytym w szablonie (nie wiem, jak przetłumaczyć template) OIDzie (.1.3.6.1.4.1.9.10.77.1.2.3.0) same zera. I wygląda na to, że w prosty sposób nie da się tego zrobić. Jedyne, co mi – na razie – przychodzi do głowy, to napisanie jakiegoś wrappera do CLI, ale eleganckie to to nie będzie…

Jakiś czas próbowałem się zaprzyjaźnić z VIMem jako „edytorem programisty”. Konkretnie chodziło o napisanie dość prostego programiku w ANSI C. Znalazłem sobie fajny skrypt/dodatek o nazwie „c.vim„, który bardzo ułatwia tworzenie i testowanie kodu we wspomnianym języku, jednak natknąłem się na dość poważny problem: nie umiałem poustawiać zmiennych c.vim’a tak, aby linkował zewnętrze biblioteki (czyli „przekazywał” do gcc parametry -lthreads albo podobne).
Chociaż nadal nie bardzo wiem, jak to zrobić poprawnie (ogólnie moja wiedza o VIMie jest raczej skromna), to znalazłem pewne obejście: do pliku ~/.vimrc dodać taką linijkę:

let g:C_Libs = '-lm -lpthread'

Wprawdzie działa to w odniesieniu do wszystkich „projektów”, które otwieram z VIMie, ale jest jednak bardziej eleganckie od ręcznego grzebania w samym c.vim’ie.