For couple of months I was struggling with ZSH history to find XRandR commands that enables and disables external screen. During that time I was almost sure that there is another way of handling this task … since eg. Gnome was doing it automatically. First idea was to find part of Gnome that is responsible for this feature and simply just integrate it with Aersome WM. But my from-time-to-time raw searches didn’t snow any interesting resources. Therefore I’ve decided that I must done it by my self … this is how screenful project was born.

What is screenful ?

It is simple extension to Awesome WM that allows you (with little knowledge of Lua and XRandR params) automatically configure connected screen. It integrates udev drm/change event with Awesome and XRandR. First of all there is udev rule that when drm/change event appears inform screenful about output change in particular card. Then screenful will “calculate” which card output was connected/disconnected, computes screen id based on EDID and finally run configured action. When configuration file doesn’t have specified configuration for this id then screenles will append commented configuration for it and run default action.

What is unique in screenful ?

Same as Awesome WM config file, the screenful config file is a Lua script! Therefore you can do anything you can imagine when external monitor is connected/disconnected. For example you can switch mplayer default audio output when you HD TV set is connected using HDMI cable then change it back when you disconnecting HDMI cable. Also you can reorganize yours tags and windows using Awesome Lua API … and more … Honestly I doubt that you can achieve similar behaviour in any different Window Manager

Project is hosted on github if you encounter any issues or have ideas about new functionalities in screenful feel free to fork me, fill a bug or mail me

Recently I was wondering how this process could be improved or even done automatically. I had few requirements:

• it should be fully automated
• system should inform me that back up process was started and that it ends
• this notification should be done as some system pop up in X windows

So I’ve come with a solution that connects udev, DBus notification and awesome wm naughty library … and it is really simple

How it works ? When you connects back-up-device udev will pick up this event, create a symbolic link to /dev/backup, then launch backup script. This script will send a notification through DBus, this event will be received by naughty and displayed as a simple notification in Awesome WM. After sending notification signal the backup script will mount given device and launch rsync command. After successful synchronization backup device will be unmonted and another notification signal will be send to inform you that you can now disconnect it.

How to achieve this ?

First of all we need to figure out UUID of our back up device (I assume that /dev/sdb2 is yours back-up-partition) :

# blkid /dev/sdb2
/dev/sdb2: UUID="97377fed-edaf-407b-9e02-5c6cecd6dceb" SEC_TYPE="ext2" TYPE="ext3"

Then we need to create new udev rule in /etc/udev/rules.d we can call it 99-backup.rules:

ENV{ID_FS_UUID}=="97377fed-edaf-407b-9e02-5c6cecd6dceb", SYMLINK+="backup"
ACTION=="add", ENV{ID_FS_UUID}=="97377fed-edaf-407b-9e02-5c6cecd6dceb", RUN+="backup"

Of course you need to replace my UUID with one you get from blkid command. Those two lines are responsible for creating symbolic link called backup in /dev directory to device with given UUID; second line will launch backup script when device with given UUID is added.

Finally we need to create our backup script and put it into /lib/udev directory. Here is content of this script:

#!/bin/sh
 
### CONFIGURATION ###
USER="lock"
MSG_TIMEOUT=-1
 
### DO NOT MODIFY ###
function show_notification() {
	su $USER -c "export DISPLAY=':0.0'; \
		export XAUTHORITY='/home/$USER/.Xauthority'; \
		/usr/bin/dbus-send --type=method_call --dest=org.freedesktop.Notifications \
			/org/freedesktop/Notifications  org.freedesktop.Notifications.Notify string:'' \
			uint32:0 string:'' string:'$1' string:'' array:string:'' array:string:'' int32:$MSG_TIMEOUT"
}
 
function backup() {
	show_notification "Backup process started! Do NOT disconnect backup device."
	mount /dev/backup /mnt/backup
	ionice -c 3 rsync -az --delete --exclude=/dev --exclude=/mnt --exclude=/media --exclude=/run --exclude=/proc --exclude=/tmp --exclude=/sys --exclude=/var/log --exclude=/var/run / /mnt/backup
	umount /mnt/backup
	show_notification "Backup process successed! You can disconnect backup device."
}
 
backup &

In this file you only need to change USER variable to yours UNIX user name, also you can adjust MSG_TIMEOUT to your needs (-1 means that default value will be taken). Most difficult part in this script was to figure out how to send DBus notification from root to regular user, since all window managers create and listen on theirs own session scoped buses. As you can notice we can force dbus-send command to send signal to proper bus instance by executing this command on behalf of  given user and with exported DISPLAY and XAUTHORITY variables.

Full source code is available on github. Have a nice and pleasant back up’s

Few days ago the new version of vanilla kernel (2.6.38.4) was released, two or three days before the new version of bfs (401) was also released. Unfortunately -ck patches didn’t get an update, so I’ve decided to play a little bit with it.

First of all I’ve spotted that -ck apples bfs as a first patch, so second step wast to find out where bfs patch ends … this was a really easy task. With this knowledge I could easily extract old version of bfs from -ck3. Then both patches can be contacted and applied on vanilla 2.6.38.4. First compilation shows that function above_background_load was removed from bfs401, fortunately it was used only once

I’m using this kernel (2.6.38.4-ck3-bfs401) for two days without any problems so it seams that my combination of those patches doesn’t brake anything. If you want to try this on your own, here is 2.6.38.4-ck3-bfs401.patch

Thanks to Arend van Spriel this issue were fixed but patch that was send on linux-wireless mailing list doesn’t apply on vanilla 2.6.37 sources.  To get this working I decided to back port this patch, and it appears to be was very simple task . So if you are have similar problems with BCM4727 on 2.6.37 like I had here is a patch that clearly apples on 2.6.37 and fix this issue.

diff -uNr drivers-orig/staging/brcm80211/sys/wl_mac80211.c drivers/staging/brcm80211/sys/wl_mac80211.c
--- drivers-orig/staging/brcm80211/sys/wl_mac80211.c	2011-01-05 01:50:19.000000000 +0100
+++ drivers/staging/brcm80211/sys/wl_mac80211.c	2011-01-13 17:28:50.000000000 +0100
@@ -299,7 +299,6 @@
 	wl_info_t *wl = hw->priv;
 	ASSERT(wl);
 	WL_LOCK(wl);
-	wl_down(wl);
 	ieee80211_stop_queues(hw);
 	WL_UNLOCK(wl);
 
@@ -336,6 +335,14 @@
 static void
 wl_ops_remove_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
 {
+	struct wl_info *wl;
+
+	wl = HW_TO_WL(hw);
+
+	/* put driver in down state */
+	WL_LOCK(wl);
+	wl_down(wl);
+	WL_UNLOCK(wl);
 	return;
 }
 
@@ -1356,7 +1363,6 @@
 	return 0;
 }
 
-#ifdef LINUXSTA_PS
 static int wl_suspend(struct pci_dev *pdev, pm_message_t state)
 {
 	wl_info_t *wl;
@@ -1371,11 +1377,12 @@
 		return -ENODEV;
 	}
 
+	/* only need to flag hw is down for proper resume */
 	WL_LOCK(wl);
-	wl_down(wl);
 	wl->pub->hw_up = false;
 	WL_UNLOCK(wl);
-	pci_save_state(pdev, wl->pci_psstate);
+
+	pci_save_state(pdev);
 	pci_disable_device(pdev);
 	return pci_set_power_state(pdev, PCI_D3hot);
 }
@@ -1399,7 +1406,7 @@
 	if (err)
 		return err;
 
-	pci_restore_state(pdev, wl->pci_psstate);
+	pci_restore_state(pdev);
 
 	err = pci_enable_device(pdev);
 	if (err)
@@ -1411,13 +1418,12 @@
 	if ((val & 0x0000ff00) != 0)
 		pci_write_config_dword(pdev, 0x40, val & 0xffff00ff);
 
-	WL_LOCK(wl);
-	err = wl_up(wl);
-	WL_UNLOCK(wl);
-
+	/*
+	 *  done. driver will be put in up state
+	 *  in wl_ops_add_interface() call.
+	 */
 	return err;
 }
-#endif				/* LINUXSTA_PS */
 
 static void wl_remove(struct pci_dev *pdev)
 {
@@ -1452,10 +1458,8 @@
 static struct pci_driver wl_pci_driver = {
  .name  = "brcm80211",
  .probe = wl_pci_probe,
-#ifdef LINUXSTA_PS
  .suspend = wl_suspend,
  .resume  = wl_resume,
-#endif				/* LINUXSTA_PS */
  .remove   = __devexit_p(wl_remove),
  .id_table = wl_id_table,
 };
diff -uNr drivers-orig/staging/brcm80211/sys/wl_mac80211.h drivers/staging/brcm80211/sys/wl_mac80211.h
--- drivers-orig/staging/brcm80211/sys/wl_mac80211.h	2011-01-05 01:50:19.000000000 +0100
+++ drivers/staging/brcm80211/sys/wl_mac80211.h	2011-01-13 17:17:39.000000000 +0100
@@ -84,9 +84,7 @@
 	unsigned long flags;		/* current irq flags */
 #endif				/* BCMSDIO */
 	bool resched;		/* dpc needs to be and is rescheduled */
-#ifdef LINUXSTA_PS
-	u32 pci_psstate[16];	/* pci ps-state save/restore */
-#endif
+
 	/* RPC, handle, lock, txq, workitem */
 #ifdef WLC_HIGH_ONLY
 	rpc_info_t *rpc;	/* RPC handle */

BTW. This laptop works pretty good on linux. All parts seams to be working properly (I didn’t tested bluetooth, and finger print scaner because I don’t use it), there are only problems after resuming system from suspend like above described problem with BCM4727 (other problems are connected with back light changing and graphics performance).

UPDATE:

It seams that this patch is included in kernel 2.6.38-rc3

• macbook’a
• komputera w pracy
• telefonu
• odtwarzacza MP3 (a właściwie to MPC, nie MP3)

Na wszystkich tych urządzeniach nie podzielnie króluje Linux:

• macbook’a skolonizowało Gentoo
• komp w pracy też nie ugiął się przed naporem Gentoo
• telefon jest obsługiwany przez Android’a który bazuje na Linuksie
• na odtwarzaczu działa RockBox (po to żeby odtwarzać MPC SV8)

Możliwe, że nie jestem zwyczajnym użytkownikiem … ale jak widać żyję i mam się całkiem dobrze

Odpowiadając od razu na wścibskie pytania: nie, nie zamierzam instalować pingwinka na mikrofalówce czy też pralce

Początkowo zadanie wydawało się bardzo banalne … dodać repozytorium do gitosis i wszystko powinno się zrobić automatycznie … cóż tak niestety nie było. Dla potomności (oraz mojej często wątpliwej pamięci) postanowiłem opisać całą procedurę.

Będzie do tego potrzebna nam konfiguracja gitosis. Jako że jest ona przetrzymywana jako jedno z repozytoriów nie powinno być żadnych problemów z jej uzyskaniem. Tak więc jeżeli nie mamy już jakiejś kopi na dysku wywołujemy komendę:

git clone ssh://gitosis@server.z.gitem.org/gitosis-admin.git

Następnie edytujemy plik gitosis.conf w którym odajemy nowe repo:

[repo nazwa-nowego-repo]
owner = joe
description = opis

No i niby wygląda na to, że to wszystko … niestety nie jest tak łatwo, z tego co doświadczyłem to  gitosis wymaga, żeby każde repo posiadało osobną grupę o tej samej nazwie (możliwe, że można to jakoś przekonfigurować ale ja nie znalazłem takich informacji). Więc nie pozostaje nam nic innego jak dodać kolejną grupę:

[group nazwa-nowego-repo]
owner = joe
writable = nazwa-nowego-repo
members = joe

Zapisujemy zmiany i za pomocą git push wypychamy je na serwer … no to konfiguracje gitosis mamy za sobą. Teraz zostało nam jeszcze utworzyć repo ;>

Tak więc w lokalnym systemie tworzymy sobie nowy katalog albo wchodzimy do katalogu projektu który chcemy wrzucić do repo, w środku wywołujemy git init, następnie przy użyciu git add dodajemy wszystkie pliki do commit’a. Potem commit’ujemy zmiany do lokalnego repo (git commit -m “initial commit”) … no i teraz najważniejsze, dodajemy nasze zdalne repo:

git remote add dowolna-nazwa-repo ssh://gitosis@server.z.gitem.org/nazwa-nowego-repo.git

i tryumfalnie wypychamy wszystko na serwer

git push dowolna-nazwa-repo --all

To tyle, wszystko powinno działać … przynajmniej na razie u mnie działa ;>

Dziś lub jutro dodam wpis odnośnie aktualnego stanu wtyczki dodającej obsługę git’a dla Eclipse będzie to bardzo szybkie overview funkcjonalności których do tej pory użyłem/używałem.

UPDATE:
Wpis o git’cie i eclipse jest prawie gotowy, zostało mi jeszcze opisać branche’owanie, merge’owanie, push’owanie oraz pull’owanie i wstawić screenshot’y

UPDATE2:
Dziś git też mnie pokonał … okazało się, że aktualnie plugin nie wspiera merge’owania branche’y, a push’owanie i fetch’owanie jest zbyt skomplikowane żeby opisywać je w jednym wpisie (zwłaszcza jeżeli nie ma się z tym zbyt wiele doświadczenia). Postaram się skończyć wpis jutro (zapamiętać: jutro nigdy nie umiera ) i go opublikować.

Czym jest gitosis i o czego będzie nam potrzebne?

Cóż, podobnie jak sam git, gitosis jest zestawem skryptów ułatwiającym prace z repozytorium. Zestaw tych skryptów odpowiedzialny jest za kontrolę dostępu do repo jak i za sam dostęp do niego.

Jak działa gitosis?

“Integruje” się ono z serwerem SSH, “integruje się” to za wiele powiedziane, bo sshd wykorzystywane jest tylko do autoryzacji użytkowników oraz transferu danych z i do repo. Samo gitosis nie uruchamia dodatkowego daemona, jak już wspomniałem korzysta z sshd.

Jak przebiega proces autoryzacji ?

Podobnie jak w GitHub‘ie najpierw trzeba dodać nasz klucz publiczny, żebyśmy mogli zostać z autoryzowani, następnie przy każdej próbie połączenia z repo będzie on wykorzystywany do przeprowadzenia autoryzacji … nie ma w tym żadnej wielkiej filozofii, dorzycamy nasz klucz i wszystko po prostu działa.

Ok, więc może w końcu do sedna … zaczynamy od zainstalowania pakietu gitosis w systemie:

apt-get install gitosis

Proces instalacji sam utworzy w systemie konto użytkownika (standardowy login to gitosis), założy mu katalog domowy (standardowo: /srv/gitosis). Jeżeli bardzo chcemy to możemy to zmienić korzystając ze standardowej komendy usermod dla uproszczenia ja będę się posługiwał standardową nazwą użytkownika. Pozostaje nam tylko inicjalizacja i konfiguracja:

sudo -H -u gitosis gitosis-init < id_rsa.pub

Gdzie id_rsa.pub jest naszym kluczem publicznym używanym przez naszego klienta ssh … fajnie to brzmi ale co to właściwie jest ? Dokładny opis jak taki klucz sobie wygenerować (i co z nim zrobić) znajduje się tutaj. Generalnie powinien być to klucz który będzie identyfikował naszą maszynę z której będziemy się łączyć do repozytorium (tj. klucz prywatny i publiczny powinny być zapisane w katalogu ~/.ssh na twoim desktopie/laptopie, tylko klucz publiczny w celu instalacji go w konfiguracji gitosis powinieneś skopiować na serwer na którym instalujesz repozytorium). Powyższa komęda powinna zainicjalizować repozytorium git/gitosis oraz dodać wskazany klucz publiczny jako klucz administratora. Jeżeli mamy szczęście to po wykonaniu poniżeszej komędy na naszym desktopie/laptopie (tj. na tym na którym znajduje się para ~/.ssh/id_rsa i ~/.ssh/id_rsa.pub):

git clone gitosis@adres_serwera:gitosis-admin.git

Jeżeli powyższa komenda nie wykona się poprawnie (jak to było w moim przypadku) zmuszeni jesteśmy skonfigurować gitosis ręcznie. W tym celu udajemy musimy przeedytować plik /srv/gitosis/.ssh/authorized_keys (tak wiem, że nie powinno się go edytować … ale co nam pozostaje ?) i zmienić “domyślny” login na identyczny z tym podanym w komentarzu do naszego klucza prywatnego (to jest to co podaliśmy za przełącznikiem -C podczas jego tworzenia), wartość klucza publicznego (to jest ten dziwny ciąg znaków za ssh-rsa) oraz na samym końcu ponownie wstawiamy wartość z naszego komentarza. Po wykonaniu tych zmian i ich zapisaniu ponownie próbujemy sklonować repozytorium z konfiguracją (czyli jeszcze raz wydajemy poprzednią komendę) … jeżeli znowu nie wykona się poprawnie … cóż czasem trzeba sobie radzić samemu

Ok, zakładam że w końcu uda się pobrać z serwera konfigurację z serwera … tak, na prawdę gitosis przechowuje swoją konfigurację w formie jednego z repozytoriów. Jest to dość wygodne, gdyż nie wymusza na nas logowania się na serwer celem zmiany konfiguracji (w wypadku dodania użytkownika repozytorium, czy też nowego projektu). W każdej chwili możemy sobie ta konfigurację pobrać, zmodyfikować, “wepchnąć” z powrotem i usunąć jak dla mnie bomba .

Co do samej konfiguracji to składa się ona z 2 rzeczy:

• pliku z konfiguracją (znajdują się tam definicje repozytoriów, grup i praw dostępu)
• katalogu z kluczami publicznymi użytkowników

W katalogu keydir/ znajdują się klucze publiczne użytkowników, w postaci:

uzywany_login.pub

najczęściej login ma postać adresu email, więc przykładowy plik dla użytkownika wlodek@luksza.org będzie się nazywał wlodek@luksza.org.pub … jest to niezmiernie skomplikowane, nieprawdaż

W przypadku kiedy chcemy dodać nowego użytkownika bądź repozytorium musimy przeedytować plik gitosis.conf, jego opis można znaleźć tutaj. W przypadku użytkowników należy pamiętać o zgodności nawy użytkownika z nazwą pliku zawierającą jego klucz publiczny. Dodatkowo warto wspomnieć o tym, że dla każdego repozytorium możemy zdefiniować właściciela (parametr owner ) oraz opis (description), są to przydatne parametry zwłaszcza podczas eksploracji repozytorium przy użyciu cgit‘a czy też gitweb‘a.

Kiedy już wykonamy wszystkie zmiany commit’ujemy je do lokalnego repo, a potem wypychamy do głównego:

git commit -a
git push

W ten prosty sposób administrujemy repozytorium git’a zarządzanym przez gitosis

BTW. Chyba szykuje się nam zmiana na miejscu domyślnego repo Eclipse Fundation możliwe, że nowe repo będzie obsługiwane przez git’a, “pierwsze” takie przesłanki można znaleźć tutaj.

Moje oczekiwania od takiego repo są następujące:

• dostępność do repo z każdego zakątka świata (czyli serwer musi być dostępny szeroko pojętej sieci)
• możliwość dostępu do repo tylko dla wybranych użytkowników
• możliwość przeglądania repo z poziomu www
• bezpieczeństwo stosowanego rozwiązania (https, ssh)

Jakie wybrałem oprogramowanie ?

• systemem bazowym będzie Debian (znany, lubiany i standardowy linux)
• gitosis (prosty soft do hostowania repozytorium git’a z równie prostą kontrolą dostępu, IMO rozwiązanie w sam raz do moich potrzeb)
• lighttpd (mały i szybki httpd)
• mod_ssl oraz mod_auth do wyżej wymienionego httpd
• cgit odpowiednik gitweb’a ale moim zdaniem ładniejszy i bardziej przejrzysty

We własnym zakresie trzeba zadbać o system bazowy, oraz jego konfigurację . Zakładam, że Debian jest już zainstalowany, skonfigurowany, zabezpieczony oraz podpięty do sieci.

Zaczynamy od instalacji i konfiguracji lighttpd

apt-get install lighttpd apache2-utils

Pakiet apache2-utils będzie nam potrzebny do wygenerowania hash‘a hasła potrzebnego do mod_auth (swoją drogą system pakietowania debiana coraz bardziej mnie zadziwia … nie rozumiem po co w zależnościach do tego pakietu znajduje się libmysqlclient …). Po zainstalowaniu włączamy dwa interesujące nas moduły:

lighttpd-enable-mod auth
lighttpd-enable-mod ssl

Oraz przechodzimy do konfiguracji zarówno httpd jak i modułów. Zaczniemy od mod_auth, czyli edytujemy pliczek /etc/lighttpd/conf-enabled/05-auth.conf, w którym to wybieramy backend (czyli algorytm szyfrowania haseł oraz miejsce ich zapisu) oraz konfigurujemy miejsca do których dostęp będzie strzeżony hasłem. Po modyfikacjach plik konfiguracyjny powinien wyglądać mniej więcej tak:

## Authentication for lighttpd
##
## Documentation: /usr/share/doc/lighttpd-doc/authentication.txt.gz
##                http://www.lighttpd.net/documentation/authentication.html
server.modules                += ( "mod_auth" )
# htdigest jest najmocniejszym dostepnym "algorytmem" szyfrujacym
auth.backend                   = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/lighttpd-htdigest.user"
 
auth.require                 = ( "/" =>
                                     (
                                       "method"  => "digest",
                                       "realm"   => "secure content",
                                       "require" => "valid-user"
                                      )
                                )

Opcja auth.require zawiera tylko jeden element, którym jest root serwera httpd, czyli dostęp do dowolnego pliku na serwerze będzie chroniony hasłem. Warto tutaj wspomnieć, że hash hasła zostanie posolony wartością w realm, dzięki temu uzyskujemy prosty mechanizm kontroli dostępu (tj. gdybyśmy mieli dwa zasoby z różnymi wartościami w realm, każdego użytkownika który powinien posiadać dostęp do obu powinniśmy dodać osobno). Teraz wystarczy tylko dodać użytkownika:

htdigest -c /etc/lighttpd/lighttpd-htdigest.user 'secure content' user_name

Po wydaniu tej komendy zostaniemy poproszeni o podanie oraz potwierdzenie hasła dla tego użytkownika.

Po skonfigurowaniu mod_auth przechodzimy do konfiguracji mod_ssl, w tym celu edytujemy /etc/lighttpd/conf-enabled/10-ssl.conf. Ja zdecydowałem się udostępniać usługę http tylko na porcie 443 z szyfrowaniem (czyli popularny https ), więc w konfiguracji mod_ssl wskazałem na którym dokładnie adresie IP oraz na jakim porcie ma nasłuchiwać daemon; plik konfiguracyjny wygląda mniej więcej tak:

## lighttpd support for SSLv2 and SSLv3
##
## Documentation: /usr/share/doc/lighttpd-doc/ssl.txt
##      http://www.lighttpd.net/documentation/ssl.html
 
#### SSL engine
$SERVER["socket"] == "111.222.3.4:443" {
ssl.engine                  = "enable"
ssl.pemfile                 = "/etc/lighttpd/server.pem"
}

następnie generujemy certyfikat self-signed dla naszego serwera:

openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes

Który to kopujemy do /etc/lighttpd/server.pem.

Ostatnią częścią konfiguracji lighttpd będzie ogólna konfiguracja serwera, czyli edytujemy plik
/etc/lighttpd/lihttpd.conf. W którym to odkomentowujemy tylko linie:

server.bind = "localhost"

Spowoduje to, że port 80 zostanie otwarty tylko na interfejsie loopback, co w konsekwencji prowadzi do tego, że wszystkie połączenia (z sieci) do portu 80 będą odrzucane (za to akceptowane będą połączenia do portu 443, zgodnie z konfiguracją w pliku 10-ssl.conf).

Na razie to wszystko w kwestii konfiguracji lighttpd, wrócimy jeszcze do niej podczas konfiguracji cgit’a. W następnej części zajmiemy się konfiguracją gitosis.

PS. Tutaj jest część druga.

Niestety, używam dość egzotycznego window managera który zwie się Awesome. Posiada on funkcjonalność auto organizacji okien na pulpicie co jak się okazuje nie podoba się Javie 1.5 wzwyż. Winę za to ponosi zmieniony w JRE 1.5 backend do komunikacji z X-Window, JRE do wersji 1.4 korzystało z Motif, natomiast w późniejszych z Xtoolkit/XAWT które to nie jest kompatybilne z ICCCM (cokolwiek to znaczy ). Warto tutaj wspomnieć ze pośrednio może tutaj tez być winne JetBrains gdyż ciągle korzystają z AWT, a nie Swing‘a …

Rozwiązania ?
Są dwa. Pierwsze bardziej drastyczne uruchamiać InteliJ z wykorzystaniem JRE 1.4 – tego nie próbowałem ale teoretycznie powinno zadziałać. Drugie rozwiązanie posiada pewien haczyk, gdyż (jak się domyślam) 64-bitowa wersja Javy nie posiada wsparcia dla Motif; osoby posiadające 64-bitowe maszyny i systemy operacyjne z 64bitowa maszyna wirtualna ustawiona jako domyślną muszą dodatkowo zassać i gdzieś umieścić wersje 32-bitowa JDK/JRE. Oprócz 32-bitowej maszyny wirtualnej musimy dodać zmienna środowiskową AWT_TOOLKIT ustawiona na MToolkit. Ja zmodyfikowałem sobie plik bin/idea.sh dodając w linii 59 taki oto fragment:

# fixes for Awesome WM
export AWT_TOOLKIT="MToolkit"
IDEA_JDK="/ścieżka/do/jdk-x86"

Jako, że serwer jest dostępny publicznie, a hostować ma nie publiczne projekty przydało by się go trochę zabezpieczyć … z administrowaniem serwerami nie miałem wiele wspólnego, ale od czego jest Google

W sieci znajduje się kilka opisów co można poprawić w standardowym Debianie żeby zwiększyć jego bezpieczeństwo. Oprócz samych zabezpiczeń warto tez być na bierząco informowanym o stanie systemu. Informacje takie możne nam dostarczyć program logcheck (wraz z logcheck-database), tylko ze jakoś te informacje muszą do nas trafić, tutaj z pomocą przychodzi … poczta elektroniczna, czyli popularne e-maile .

Wszystko było by fajnie gdyby nie to, że w momencie wysyłania wiadomości Debian usilnie korzysta z lokalnego MTA (tj. mail transport aget … domyślnie jest to exim4), co nie do końca jest fajne (jest to osobny daemon, dodatkowe otwarte porty itp.) zwłaszcza jeżeli tuz obok stoi dedykowany serwer pocztowy.

W tej sytuacji instalujemy heirloom-mailx, programik ten (po odpowiednim skonfigurowaniu) pozwala używać dowolnego zewnętrznego serwera pocztowego podczas wywoływania systemowej komendy /usr/bin/mail. Potrzebna konfiguracje umieszczamy na końcu pliku /etc/nail.rc (nie mylić z /etc/mail.rc) … kiedy chcemy żeby dany użytkownik posiadał odrębną konfiguracje, to musimy wymedytować plik ~/mail.rc

set smtp-use-starttls
set from=user@jakis.host.org
set smtp=smtp.jakis.host.org
set smtp-auth-user=user@jakis.host.org
set auth-login=user@jakis.host.org
set smtp-auth-password=supertrudneitajnehaslo
set ssl-verify=ignore

Teraz możemy przetestować nasza konfiguracje wywołując:

mail nasz-adres@nasz-server.org

Jeżeli coś nie działa to zostaniemy o tym poinformowani stosownym komunikatem … BTW. jeżeli chcemy sobie debugować możemy wykorzystać przełącznik -d (jak debug ) , z tym ze należy tutaj wspomnieć, że dodanie tego przełącznika powoduje wypisanie na ekran wiadomości i … nie powoduje jej wysyłania (sic!).

Dlaczego o tym pisze ? Bo dziś zmarnowałem ładnych parę godzin(sic!) żeby się do tego dogooglac … najpierw żeby znaleźć ta paczkę, potem zęby odpowiednio skonfigurować (tutaj szczególne podziękowania należą się przełącznikowi -d …).