Przez jakiś czas zastanawiałem się jak zaprezentować swój projekt. Kolega z pracy podsunął mi pomysł z AWS (chmura Amazona). Cóż – ku mojemu zaskoczeniu nawet kiedyś tam się zarejestrowałem. Było to na tyle dawno temu, że zapomniałem już o tym fakcie 🙂 Szybko odzyskałem hasło i zarejestrowałem się w pakiecie promocyjnym.
Postawienie instancji jest całkiem intuicyjne jeśli nie są Ci obce takie pojęcia jak „Launch Instance” czy „Security Groups”. Występują one również w OpenStacku 😉 W zasadzie nie ma się co na ten temat rozwodzić. Warto wspomnieć, że jeśli często kładziesz vm-ki to za każdym razem dostają one inny IP publiczny. Trochę to utrudnia sprawę jeśli chodzi o konfigurację DNS dla usługi, którą tam odpalamy. Od razu odpowiem na pytanie: a po co wyłączać? Plan darmowy przewiduje 750h działania usług w ramach jednego konta. Jest to ilość godzin, która wystarczy spokojnie na ciągłą (i co ważne: darmową) pracę jednej vm-ki, ale jeśli w ramach swojego planu uruchomimy dwie lub więcej instncji wtedy te 750h dzieli się przez ich liczbę. Po przekroczeniu jesteśmy chargowani zgodnie z obowiązującą taryfą 😉
Wracając do samego projektu. Przy okazji odpalenia panelu na gołym schemacie bazy wyszły dwa problemy.
Brak domyślnej wartości dla wersji konfiguracji
Problem dość poważny. Powodował segfault agenta po stronie serwera. Klient podczas pierwszego połączenia nie zapisywał w bazie wersji konfiguracji (nowy klienta ma wersję 0). Podczas każdego następnego połączenia są przesyłane różne informacje systemowe a następnie klient pyta się czy jest jakaś nowa konfiguracja dla niego. Tutaj następował problem, bo klient wysyłał wersję: 0 a serwer odczytywał z bazy wartość NULL.
Rozwiązanie
Zmodyfikowałem zapytanie, które rejestruje klienta w bazie aby ustawiało numer wersji konfiguracji na 0. Alternatywnie myślę, że można by było tak zmodyfikować schemat bazy aby domyślą wartością dla tej komórki było 0 i też by to zadziałało.
brak domyślnego użytkownika
Jednym z założeń systemu jest to, że będzie można tworzyć konta zwykłych użytkowników i konfigurować od razu dla nich usługi na serwerze. Dlatego zapytanie, które odczytuje dane konfiguracyjne (w tym przypadku chodziło o kofigurację apacza) uwzględnia nazwę konta. Efekt był taki, że zapytanie nie wykonywało się poprawnie i żaden rekord się nie zmieniał w bazie.
Rozwiązanie
Do funkcji, która dodaje do bazy klienta napisałem kod, który dodaje rekord zawierający informacje na temat domyślnego konta (root) do tabelki sysusers, który poprzez system_id jest powiązany z utworzonym przed chwilą rekordem dla klienta, który się zarejestrował.
Konkluzja: Warto jest raz na jakiś czas testować jak program zachowa się na wartościach początkowych 🙂