Dni wolne od pracy

Musiałem na liście dni miesiąca zaznaczyć polskie dni wolne od pracy. Napisałem funkcję w PHP która to robi.

function dni_wolne($data)
{
$year=substr($data,0,4);
$swieta[]=$year."01-01";
$swieta[]=$year."01-06";
$swieta[]=date("Y-m-d",easter_date($year));
$swieta[]=date("Y-m-d",easter_date($year)+86400);
$swieta[]=$year."05-01";
$swieta[]=$year."05-03";
$swieta[]=$year."08-15";
$swieta[]=$year."11-01";
$swieta[]=$year."12-25";
$swieta[]=$year."12-26";
$dzien_tyg=date("N",strtotime($data));
$wynik=0;
if(in_array($data,$swieta)) $wynik=2;
if($dzien_tyg==7) $wynik=2;
if($dzien_tyg==6) $wynik=1;
return $wynik;
}

zwraca 0 dla dni roboczych, 1 dla sobót, 2 dla niedziel i świąt.

Ponieważ używam Smarty napisałem plugin pozwalajacy w szablonach na sprawdzenie czy dzień z podaną datą jest dniem wolnym od pracy:

/**
 * Smarty plugin
 * @package Smarty
 * @subpackage plugins
 */
include_once("dni_wolne.php");

function smarty_modifier_dzien_wolny($data)
{
  return dni_wolne($data);
}
?>

w głównym folderze lub gdzieś w ścieżce szukania PHP trzeba zapisać plik z funkcją dni_wolne().

Głupi problem z IE9

Przeniosłem pewien serwis z testowego serwera pracującego na Ubuntu 9.04 na produkcyjny serwer pracujący na Ubuntu 10.04. Po przeniesieniu bazy, aplikacji itd. wszystko działało doskonale w Firefox i Chrome ale w żaden sposób nie mogłem zalogować się pod IE9. Zmarnowałem ze trzy godziny na próby, testy i debugowanie serwisu i nic. Nie ustawiał się plik sesji - a w zasadzie ustawiał się ale zaraz tworzone były jeszcze dwa nowe o zerowej długości.

Może dlatego że robiłem to w nocy, a sprawa wydawała się prosta nie wpadłem, żeby zapytać dr Google o zdanie. Następnej nocy zrobiłem to i w gąszczu różnych materiałów znalazłem odpowiedź - problem jest trywialny, chociaż nie niem co strzeliło programistom MS do głowy żeby wprowadzić taką funkcję.

Okazało się, że problemem jest znak podkreślenia w nazwie serwera. Nazwałem produkcyjny serwer http://xx_yyyy.m2s.pl i wszystko niby powinno działać. Jednak znak podkreślenia nie jest standardowym znakiem w nazwach domenowych (ciekawe dlaczego) i IE stwierdzał, że nie wolno ustawiać cookies na takich adresach.

Wystarczyło zmienić nazwę serwera usuwając znak "_" i wszystko gra i buczy nawet w IE.

Problemy z adresami IP FailOver na serwerze dedykowanym w OVH

W ostatni czwartek pracowaliśmy na nowo skonfigurowanym XenServer, ja instalowałem sobie maszynę na SLES 11 (64) - wszytko bardzo ładnie chodziło. Aż ty w pewnej chwili straciliśmy dostęp po IP do wszystkich maszyn wirtualnych. Sam XenSerwer chodził bez problemów. Maszyny wirtualne jak się okazało też, tylko nie miały połączenia z routerem.
Ponieważ dopiero zaczynam używanie usług tej francuskiej firmy, nie wiedziałem co zrobić szybko usunęli problem.
O 17:23 w czwartek wysłałem na adres pomoc@ovh.pl e-maila z opisem usterki. Potem zobaczyłem że w Managerze jest opcja do zgłaszania awarii - zgłosiłem i o 17:56 dostałem potwierdzenie z numerem zgłoszenia. Określiłem zgłoszenie jako "pilne" - w końcu nie miałem dostępu do swoich serwerów.
Jeszcze przed 18 zadzwoniłem na podanych na stronach numer telefonu we wrocławskiej strefie numeracyjnej dedykowany do zgłoszeń awarii - niestety miła pani spytała się czy mówię po angielsku (niestety nie bardzo) i zaproponowała żebym zadzwonił następnego dnia.
No to zadzwoniłem do pomocy technicznej - tutaj już po polsku pani poprosiła mnie o zgłoszenie awarii e-mailem (już to wcześniej zrobiłem). W międzyczasie posprawdzałem opcje monitoringu żeby wiedzieć kiedy zacznie działać.
Rano następnego dnia (8:11) dostałem dodatkową prośbę o opis konfiguracji - podałem wszystkie posiadane dane (w zasadzie te co poprzednio w zgłoszeniu) i o 9:31 wysłałem do OVH. O 9:39 dostałem info że dane zostały przekazane dalej.
O 11:22 dostałem informację e-mailem, że powtórnie wykonano ACL co spowodowało odblokowanie naszych adresów i wszystko wróciło do poprzedniego stanu. A o 11:27 włączony wcześniej monitoring poinformował, że monitorowane usługi znowu działają prawidłowo.
Na moje oko, sami coś popsuli w ustawieniach ACL na routerze i mogli szybko poprawić, a jedynym problemem jest, że technicy w Polsce pracują od 8 do 18.
Reasumując cały proces od zgłoszenia do usunięcia problemu trwał 18 godzin i tyle czasu nie było dostępu do serwerów - całe szczęście całość jest dopiero w trakcie konfiguracji. Nauczyłem się jak obchodzić się z pomocą techniczną i że niestety za określoną cenę dostaje się określone wsparcie techniczne - cóż nie ma róży bez kolców, nie można mieć wszystkiego na raz.

Instalacja Oracle-XE na wirtualnej maszynie z Ubuntu 9.10 PV

Często do celów testowych czy nauki potrzebujemy mieć dostęp do bazy Oracle 10g, nie chcemy ustawiać specjalnego serwera tylko do tego celu. Całkiem dobrze sprawdzi się maszyna wirtualna pracująca pod XenServer 5.5/5.6 z systemem Ubuntu 9.10.

KROK 1
Zakładam, że istnieje już maszyna z XenServer w wersji 5.5/5.6. Najpierw należy pobrać gotowy template dla maszyny wirtualnej. Ponieważ Oracle XE jest systemem 32-bitowym potrzebna jest właśnia taka wersja dysterybucji Linuxa. Ja znalazłem gotowe wzorce pod adresem http://www.isaaczarb.com/ubuntu-9-10-for-citrix-xenserver-5-x/ , gdzie jest ładnie opisane jak zainstalować template na XenServer.

KROK 2
Mamy już pobrany plik Ubuntu-9.1032bitPV.7z, który musimy rozpakować otrzymując Ubuntu-9.1032bitPV.xva . Teraz uruchamiamy XenCenter i po zalogowaniu się do serwera wybieramy File > Import.
Pokazuje dialog do z polem do podania lokalizacji pliku *.xva. Wybieramy nasz plik template, podajemy na jakim serwerze ma zostać zainstalowana maszyna wirtualna,  gdzie ma być umieszczony obraz dysku, parametry karty sieciowej i rozpoczyna się importowanie wzorca na serwer. W zależności od szybkości łącza trwa to krócej lub dłużej, trzeba przetransferować ok 7GB danych.

KROK 3
Maszyna powinna się już uruchomić, trzeba wejść na zakładkę konsoli i zalogować się. Na początku login to: root, a hasło: password. Po zalogowaniu się warto od razu zmienić hasło. Trzeba teraz sprawdzić adres sieciowy, który maszyna uzyskała z DHCP, ewentualnie ustawić statyczny adres IP.

KROK4
Instalacja Oracle - najłatwiej pobrać oprogramowanie bezpośrednio z repezytorium Oracle w następujący sposób:

1. Nasza maszyna jest odpowiednio skonfugurowana do obsługi Oracle XE, ma odpowiednio dużo pamięci i odpowiednio wielki SWAP. Dlatego nie trzeba przeprowadzać zmian potrzebnych po standardowej instalacji Ubuntu.
2. Edytujemy plik /etc/apt/sources.list dopisując na końcu linię: deb http://oss.oracle.com/debian unstable main non-free
3. Pobieramy klucz GPG niezbędny do pobierania pakietów: $ wget http://oss.oracle.com/el4/RPM-GPG-KEY-oracle -O- | sudo apt-key add -
4. Wykonujemy aktualizację bazy pakietów: $ sudo apt-get update
5. Instalujemy Oracle XE: $ sudo apt-get install oracle-xe-universal
6. Po zakończeniu pobierania (ok 260 MB) i instalacji dostajemy informację o potrzebie konfiguracji Oracle XE. Nalezy podać komendę: $ sudo /etc/init.d/oracle-xe configure
7. Podajemy kolejno port na którym będzie dostępne narzędzie webowe [8080], port na którym będzie dostępny "database listener" [1521], oraz hasło dla użytkownika na którym będzie pracował serwer Oracle. To hasło jest jednocześnie początkowym hasłem dla użytkowników SYSTEM i SYS.
8. Teoretycznie po wykonaniu powyższych operacji powinniśmy uruchomić w lokalnym systemie przeglądarkę i wybrać adres http://localhost:8080/apex żeby skonfigurować użytkowników, zmienić hasła itd. Ale przecież nasz system nie ma środowiska graficznego - jest jednak łatwe rozwiązanie tego problemu.
9. Mając stację z Windows, na której działa XenCenter trzeba uruchomić tunelowanie portów poprzez SSH. Najwygodniej użyć programu PortForwarder dostępny ze strony: http://toh.fuji-climb.org/pf/
10. Po pobraniu archiwum zip i rozpakowaniu go w dogodnym miejscu należy w pliku config.txt dopisać sekcję np. (oczywiście adresy ip trzeba odpowiedio zmienić):
    
Host oracle-xe
    HostName 192.168.87.67
    User root
    LocalForward 8080 127.0.0.1:8080
    Compression yes
11. Na stacjach z systemem Linux można stworzyć tunel poleceniem:
    

    ssh -L 8080:localhost:8080 user@IP_of_your_server

12. Można też użyć Putty i skonfigurowac tunel w ramach połaczenia.
13. Po uruchomieniu programu zostaniemy zapytani o hasło użytkownika root i jeżeli wszystko poszło tak jak trzeba, program się zminimalizuje.
14. Uruchamiamy na lokalnym komputerze przeglądarkę wpisując adres http://127.0.0.1:8080/apex - powinna się ukazać strona logowania serwera apex. Po podaniu jako login: system oraz hasła które ustalilismy podczas konfiguracji, powinniśmy uzyskać dostęp do aplikacji. Na początek warto odblokować dostęp przez http z innych hostów w sieci, co pozwoli mieć dostęp do zarządzania ze swojego komputera.
15. Teraz wystarczy sprawdzić dowolnym narzędziem np. Oracle SQL Developer (http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html), Aqua Studio (http://www.aquafold.com/aquadatastudio.html), Toad for Oracle (http://www.toadworld.com/Freeware/tabid/680/Default.aspx) czy wszystko działa. Jako  SSID bazy danych należy podać XE.

Opisany sposób nie wymaga instalacji środowiska graficznego na serwerze, mnie na maszynie XenServer z jednym czterordzeniowym procesorem Xeon i pamięcią 12 GB zajęło to ok. godzinę czasu.

Jak już serwer Oracle działa, można np. utworzyć użytkowników, schematy, zaimportować dane i pracować. Takie rozwiązanie sprawdziło się nawet w niewielkiej bazie z aplikacją w Java dla 10 użytkowników, obrabiającą tabele po kilka milionów wierszy.

VoIP w praktyce

Od dwóch czy trzech lat używałem telefonii VoIP w firmie i w domu. Ale zawsze był to ten drugi telefon, tańszy ale o gorszej jakości i mniej niezawodny. Jednak w końcu trzeba się przełamać, a technologia się sprawdziła. W jakości połączenia nie słyszę różnicy, niezawodność podobna jak w zwykłym telefonie na kablu (jakość łączy internetowych bardzo się poprawiła) - jak nie słychać różnicy to po co przepłacać?

Najpierw spróbowałem w domu. Miałem już jeden numer w Tlenofonie, działał w miarę dobrze. Zdecydowałem się na przeniesienie numeru domowego z TPSA do Tlenofonu. Wypełniłem formularze, podpisałem, wysłałem, dostałem potwierdzenie i czekałem. I faktycznie po ok 60 dniach tak jak pisali pojawił się w Tlenofonie mój stary numer z TPSA. Teraz jeszcze połączyłem obydwa numery na wspólnym koncie rozliczeniowym i zamiast 50 zł miesięcznie płacę 50 zł raz na 3 miesiące, mam dwie linie podłączone do mojej starej ale dobrej domowej centralki PMS-08 firmy Slican (Polskie to dobre).

Od kilku miesięcy działa bez problemu, stary numer (podajemy w wielu miejscach - dlatego lepiej nie zmieniać) działa, wszystko gra i buczy. Na dokładkę kupiłem wirtualny faks dla firmy (na oddzielnym numerze) i mam wszystko czego mi trzeba.

Mając pozytywne doświadczenia zaproponowałem przy okazji zmiany siedziby firmy w której pracuję, aby także uniezależnić się od kabelków. W końcu mamy łącze światłowodowe, które bez problemu obsłuży nasze numery.

Mamy w IPFon 10 numerów więc jakoś trzeba było je ogarnąć. Poszukaliśmy centralki z obsługą linii miejskich VoIP - najtańsza okazała się polska produkcja znanej mi od kilkunastu lat firmy Slican. Centralka obsługuje 8 linii miejskich VoIP, ma założone dwa moduły GSM oraz łącznie 12 linii wewnętrznych analogowych i 12 linii VoIP wewnętrznych.

Przyszedł specjalista, zainstalował wszystko, podłączyliśmy nasze numery tak aby część miało priorytet na wejściowe a pozostałe działały jako wyjściowe. I po prostu działa. Ponieważ wszyscy pracownicy mają telefony komórkowe i w grupie rozmawiamy praktycznie za darmo to bardzo często jak ktoś dzwoni z zewnątrz na numer miejski jest przez recepcję przełączany na komórkę pracownika (i nawet o tym nie wie). Zrobiliśmy sobie proste reguły przekazywania połączeń w razie nieobecności co właściwie wyczerpało postulaty sekretariatu i recepcji.

Ponieważ po wewnętrznej sieci są linie VoIP to mogłem podłączyć się VPN i z mojego notebooka (przy pomocy X-Lite) mam telefon wewnętrzny wszędzie gdzie jestem. Taki wewnętrzny skype.

Na koniec - cała firma (ok 100 pracowników) jest obsługiwana przez VoIP - nie mamy innych linii, faksy też na tym chodzą. I działa. Raz może zawiesiło się coś na centrali ale wystarczyło zresetować i wróciło do normy. Koszty obsługi telefonów spadły do 30% poprzednich wydatków (mieliśmy linie TPSA na miasto), różnica w jakości jest niewyczuwalna, można powiedzieć wdrożenie się udało.