Nginx

Harmonogram aktualizacji

Serwery będą aktualizowane partiami – oto informacja, w którym dniu odbędą się prace na wybranych serwerach:- 07.09.2018 00:30: s0, s11;- 08.09.2018 00:30: s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s12, s13, s14, s15;- 09.09.2018 00:30: s16, s17, s18, s19, s20, s21, s22, s23, s24, s25, s26, s27, s28;

Wykonany zostanie również restart systemu – prosimy upewnić się, że wszystkie aplikacje, które mają uruchomić się automatycznie po restarcie są dodane do zadań cron.Aplikacje uruchomione przez użytkowników ze względu na aktualizacje w systemie mogą wymagać ponownej kompilacji.

Przerwy w działaniu mogą potrwać do godziny 02:00. Za utrudnienia przepraszamy.

Domyślna wersja PHP

Zapowiadamy zmianę domyślnej wersji PHP dla serwerów s0-s28 z wersji 5.6 na 7.1. Zmiana zostanie wprowadzona dnia 10.01.2019.Dla nowych serwerów (s29+) PHP 7.1 jako domyślna wersja zostaje wprowadzona już teraz.

Aby dla stron aktualnie działających na PHP 5.6 pozostawić tę wersję należy dodać do pliku .htaccess:AddType application/x-httpd-php56 .php

W przeciwnym razie po dniu 10.01.2019 strona zacznie korzystać z PHP 7.1.

.htaccess kompatybilny z Apache 2.4

Po aktualizacji nasz Nginx będzie kompatybilny z formatem .htaccess dostępnym w Apache 2.4, nie powinno to powodować problemów z działaniem aktualnie używanych regułek (zgodność na poziomie Apache 2.2).

Usunięcie wersji 4 oraz 9 Node.js

Zgodnie z wcześniejszą zapowiedzią Node.js 4 oraz 9 zostaną usunięte podczas aktualizacji. Wszystkie strony korzystające z tych wersji zostaną przeniesione na wyższe:Node.js 4 -> 6;Node.js 9 -> 10;

Proszę upewnić się, że uruchomione strony są kompatybilne z nowszymi wersjami Node.js.Aplikacje Node.js mogą wymagać rekonfiguracji po aktualizacji systemu.

Dostępne wersje Node.js po aktualizacji: 6, 8 oraz 10.

Python

Zostanie dodana najnowsza wersja Pythona: 3.7.Podobnie jak przy Node.js Twoja aplikacja również może wymagać reinstalacji/ponownej kompilacji modułów.

Dostępne wersje Python po aktualizacji: 2.7, 3.4, 3.5, 3.6 oraz 3.7.

Ruby 

Gemy mogą wymagać przebudowania ze względu na zmiany wersji systemowych bibliotek – bez tego aplikacje oparte o Ruby, Ruby on Rails mogą nie zadziałać prawidłowo po aktualizacji (dotyczy to również m.in. Redmine).

Jeżeli po aktualizacji masz problem z działaniem lub uruchomieniem aplikacji to skontaktuj się z nami bezpośrednio poprzez system ticketów lub adres e-mail: pomoc@mydevil.netWiadomość e-mail musi zostać wysłana z adresu kontaktowego dla usługi (w panelu płatności można dodać techniczne adresy kontaktowe) jak i zawierać jak najwięcej informacji o problemie (jakiej aplikacji lub strony WWW dotyczy problem).

RVM / własne środowisko Ruby

Przygotowania do wprowadzenia systemu zarządzania kontem Devil2 oraz panelu WWW DevilWEB2 na mydevil.net idą pełną parą. Więcej informacji o migracji na nowe rozwiązania już wkrótce, a dzisiaj mamy dla Was kolejną nowość – nowa obsługa Ruby, która umożliwia uruchomienie strony na własnym środowisku. Co to oznacza?

* możesz zbudować niezależne środowisko, które nie będzie wrażliwe na zmiany w konfiguracji naszego systemu – zapewnia to ciągłość działania aplikacji;

* obsługa dowolnych wersji Ruby oraz Gemów;

* aplikacje są uruchamiane automatycznie po pierwszym wejściu na stronę – nie musisz więcej martwić się o uruchamianie procesów.

Nowe polecenia

Dodane zostały następujące polecenia:

* devil www add <DOMENA> ror <RUBY_BIN> – dodaje domenę z obsługą Ruby;

* rvm-libs <RUBY_BIN> <DOMENA> (dostępne tylko na serwerze WEB) – buduje niezależne środowisko dla RVM w katalogu domowym użytkownika.

Zmienne:

– <DOMENA> – adres, pod którym będzie widoczna aplikacja Ruby;

– <RUBY_BIN> – pełna ścieżka do binarki Ruby znajdująca się w katalogu użytkownika na serwerze WEB.

Budowa nowego środowiska w katalogu domowym

Zalecamy przeniesienie aplikacji na własne środowisko jak najszybciej – z dużym prawdopodobieństwem aplikacje działające pod typami ror18, ror19 oraz thin przestaną działać, jeśli nie dokonasz zmian. Można tego dokonać w następujący sposób (jeśli już posiadasz zbudowane środowisko możesz ten krok pominąć):

* zbudowanie środowiska Ruby przy pomocy RVM we własnym katalogu domowym (wykonuj na serwerze WEB z włączoną opcją binexec):

curl -sSL https://get.rvm.io | bash -s stable

* przeloguj się lub wpisz (podmieniając <USER> na login konta):

source /home/<USER>/.rvm/scripts/rvm

* zbudowanie własnej wersji Ruby (w tym wypadku polecenie zbuduje najnowszą wersję – obecnie 2.1.1):

rvm install ruby –autolibs=disabled

Jeśli wszystko poszło poprawnie – masz własne środowisko Ruby we własnym katalogu domowym.

Uruchomienie aplikacji przy pomocy nowej obsługi Ruby

Podane tutaj kroki są konieczne dla typów: ror18, ror19 oraz thin:

* przejście do katalogu z uruchomioną aplikacją i zbudowanie dla niej środowiska opartego o własną wersję Ruby (dostosuj polecenie podmieniając <DOMENA> oraz ewentualne opcje bundlera):

cd ~/domains/<DOMENA>/public_ror; bundle install –path vendor/bundle –without development test sqlite3

* usunięcie starej domeny (nie usuwa danych):

devil www del <DOMENA>

* dodanie domeny z nowym typem (przykład dla najnowszej dostępnej wersji ruby – jeśli zbudowane środowisko jest dla innej – konieczna jest zmiana ścieżki):

devil www add <DOMENA> ror /usr/home/<USER>/.rvm/rubies/ruby-2.1.1/bin/ruby

W tym miejscu aplikacja powinna już działać na własnym środowisku – można to sprawdzić odwiedzając stronę.

Ostatnim krokiem jest zbudowanie niezależnego środowiska – do tego służy udostępniony przez nas skrypt o nazwie rvm-libs, przykładowe użycie (wykonać należy na serwerze WEB z włączoną opcją binexec):

rvm-libs /usr/home/<USER>/.rvm/rubies/ruby-2.1.1/bin/ruby <DOMENA>

Jeśli skrypt wykona swoją pracę poprawnie – pojawi się komunikat „[OK] Done”.

W razie jakichkolwiek problemów przy zmianie środowiska prosimy o skontaktowanie się z nami.

Migracja serwera irc.mydevil.net

W nocy z 17.03.2014 (poniedziałek) na 18.03.2014 (wtorek) na godzinę 1:00 planowana jest migracja na nowy sprzęt serwera irc.mydevil.net. Migracja będzie wiązała się z chwilową niedostępnością usług hostowanych na irc.mydevil.net w tym prywatnych adresów IP (OVH) oraz serwerów proxy: Francja, Polska, USA, Wielka Brytania. Przypominamy o możliwości dodania swoich aplikacji do cron co umożliwi ich automatyczne uruchomienie po wstaniu systemu.

Nowe publiczne adresy IP

Zostaną usunięte następujące adresy IP:

178.32.224.49 crawl-84.16.226.50.googleb0t.com

178.32.224.50 mydevil.pl

178.32.224.51 freebsd.net.pl

178.32.224.52 178-32-224-52.ovh.net

178.32.224.53 bsd.net.pl

178.32.224.54 mydevil.info

178.32.224.55 putty.pl

178.32.224.56 178-32-224-56.ovh.net

178.32.224.57 humble.mumble.pl

178.32.224.58 178-32-224-58.ovh.net

178.32.224.59 178-32-224-59.ovh.net

178.32.224.60 host17.mydevil.net

178.32.224.61 178-32-224-61.ovh.net

178.32.224.62 uzywa.nginx.pl

178.32.225.209 host21.mydevil.net

178.32.225.210 equestria.pl

178.32.225.211 178-32-225-211.ovh.net

178.32.225.212 178-32-225-212.ovh.net

178.32.225.213 host26.mydevil.net

178.32.225.214 host27.mydevil.net

178.32.226.9 host29.mydevil.net

178.32.226.10 178-32-226-10.ovh.net

178.32.226.11 xiron.mydevil.net

178.32.226.12 t80.mydevil.net

178.32.226.13 resk.nomusk.pl

178.32.226.14 niezalezny.antycenzor.pl

178.32.245.227 mylittledevil.net

178.32.245.228

178.32.245.229

178.32.245.230

178.32.245.231

178.32.245.232

178.32.245.233

178.32.245.234

178.32.245.235

178.32.245.236

178.32.245.237

178.32.245.238

W ich miejsce pojawią się adresy:

188.165.138.105

37.187.140.40 mylittledevil.net

5.135.231.129 crawl-84.16.226.50.googleb0t.com

5.135.231.130 mydevil.pl

5.135.231.131 freebsd.net.pl

5.135.231.132 bsd.net.pl

5.135.231.133 mydevil.info

5.135.231.134 putty.pl

5.135.231.135 humble.mumble.pl

5.135.231.136 uzywa.nginx.pl

5.135.231.137 equestria.pl

5.135.231.138 t80.mydevil.net

5.135.231.139 niezalezny.antycenzor.pl

5.135.231.140

5.135.231.141

5.135.231.142

5.135.231.143

5.135.231.144

5.135.231.145

5.135.231.146

5.135.231.147

5.135.231.148

5.135.231.149

5.135.231.150

5.135.231.151

5.135.231.152

5.135.231.153

5.135.231.154

5.135.231.155

5.135.231.156

5.135.231.157

5.135.231.158

5.135.231.161

5.135.231.162

5.135.231.163

5.135.231.164

5.135.231.165

5.135.231.166

5.135.231.167

5.135.231.168

5.135.231.169

5.135.231.170

5.135.231.171

5.135.231.172

5.135.231.173

5.135.231.174

5.135.231.175

5.135.231.176

5.135.231.177

5.135.231.178

5.135.231.179

Informujemy o konieczności zmian w konfiguracji aplikacji korzystających z wymienianych adresów IP.

W razie pytań lub wątpliwości zapraszamy do kontaktu.

Migracja stron na serwer webowy dobiegła końca. Poniżej zamieszczamy ważne informacje dotyczące nowej maszyny.

Przenoszenie stron

Jeśli w Twoim katalogu domowym nie pojawił się katalog o wdzięcznej nazwie ~/domains.local, to należysz do grona szczęśliwców, którym wszystkie domeny zostały przeniesione automatycznie i nic nie musisz robić (możesz całkowicie pominąć tę część newsa).

W przeciwnym wypadku polecenie devil www list pokaże listę wszystkich domen, które należy przenieść samodzielnie (przy ich katalogach pojawi się czerwony wykrzyknik), oraz zostanie wyświetlony komunikat u dołu wspomnianej listy.

Katalog ~/domains to symlink do podmontowanego zasobu NFS serwera webowego. Domeny, których nie udało się przenieść znajdują się w katalogu ~/domains.local.

Pliki można przenosić zwykłym poleceniem mv, przykład poniżej (nie należy się jednak spodziewać niewiadomo jakiej prędkości przenoszenia, NFS jest dość wolny):

rm ~/domains/example.com

mv ~/domains.local/example.com ~/domains/example.com

Następnie należy zalogować się na serwer webowy za pomocą polecenia ssh-web (przed pierwszym logowaniem należy wykonać polecenie devil www init) i uruchomić daemona danego frameworku. Przypominamy: jeśli jakaś strona użytkownika nie została przeniesiona oznacza to, że wymaga ona podjęcia dodatkowych działań (jak chociażby uruchomienie backendu). Należy też pamiętać o przeniesieniu swoich wpisów crontab, które dotyczą stron oraz zarezerwowaniu portów, z których korzystają (szczegóły poniżej).

Jeśli strona wymaga uprawnień exec (uruchamianie własnego oprogramowania), należy je włączyć poleceniem: devil binexec on mdweb.

Nie ukrywamy – może się zdarzyć, że na serwerze webowym nie ma jakiegoś modułu, który jest wymagany do uruchomienia danego backendu. Staraliśmy się przenieść wszystkie aplikacje i moduły, jednak człowiek nie jest istotą nieomylną. W takiej sytuacji prosimy o kontakt – doinstalujemy brakujący moduł.

Po przeniesieniu domeny należy „oznaczyć” ją jako przeniesioną, za pomocą polecenia devil www marknew example.com – usunie to wspomniany wcześniej czerwony wykrzyknik i zmieni ustawienia nginxa na serwerze shellowym (ruch dla tej domeny będzie od tej pory przekazywany na serwer webowy, tej operacji nie da się cofnąć).

Gdy już wszystkie domeny zostaną przeniesione, zalecamy oczyszczenie katalogu ~/domains.local i usunięcie go.

Uwaga! Na wykonanie powyższych czynności dajemy Ci 30 dni. Po tym czasie nginx na serwerze shellowym zacznie przekazywać cały ruch na serwer webowy (tak, by wszystkie adresy IP obsługiwały strony WWW).

DNSy

Domyślnie wszystkie adresy IP będą przekazywać ruch na serwer webowy (aby zapewnić przezroczystą migracje oraz umożliwić korzystanie z wszystkich adresów IP do serwowania stron WWW). Oznacza to jednak, że strony są zależne od serwera shellowego. Jeśli użytkownikowi nie robi to większej różnicy na jakim adresie IP dostępna jest jego strona, zalecamy usunięcie wszystkich wpisów typu A i AAAA z domeny i dodanie następujących:

– Wpis typu A (IPv4), kierujący na adres: 87.98.234.154

– Wpis typu AAAA (IPv6), kierujacy na adres: 2001:41d0:8:479d::80

Powyższe wpisy stały się również domyślnymi dla szablonu mydevil, używanym przy dodawaniu domeny do systemu DNS.

Ruby on Rails

Dawny typ ror został przemianowany na ror18. Jak sama nazwa wskazuje, jest to Ruby on Rails bazujący na gałęzi 1.8.x (była to domyślna wersjaRuby/RoR dla passengera na serwerze shellowym). Oprócz tego dostępny jest typ ror19, w oparciu o Ruby z gałęzi 1.9.x. Oba te typy posiadają niezależne zestawy gemów – w razie konieczności instalacji jakiegoś, prosimy o kontakt. Może też być konieczne ponowne wykonanie polecenia bundle (po usunięciu katalogu ~/.bundler/ruby/1.8 lub podobnego, zależnie od wcześniejszych ustawień) dla danej aplikacji na serwerze web (ssh-web). W przypadku błędu instalacji gemu rmagick należy dodać przed poleceniem (w tej samej linii): PKG_CONFIG_PATH=/usr/local/libdata/pkgconfig bundle (dalszy ciąg polecenia).

Quota

Wszyscy użytkownicy na serwerze webowym otrzymują quotę 20GB (niezależnie od typu konta). Limit powierzchni dyskowej nie jest wliczany do quoty na serwerze shellowym, zostanie to jasno wyszczególnione w ofercie.

FTP

FTP po zamontowanym zasobie NFS nie byłby demonem prędkości, dlatego zdecydowaliśmy się uruchomić oddzielny serwer FTP na serwerze webowym. Wystarczy dodać konto FTP dla katalogu ~/domains – devil automatycznie uruchomi nowe konto dla serwera webowego, a w odpowiedzi poda dane do nowego serwera. Obecne konta FTP dla katalogu ~/domains zostały zmigrowane na serwer web (adres: ”ftps://mdweb.mydevil.net”).

Porty

Moduł rezerwacji portów umożliwia rezerwację portów na serwerze webowym (nazwanym mdweb). Porty można rezerwować za pomocą poleceń (dane przykładowe):

devil port add tcp 12345 mdweb

devil port add udp 12345 mdweb

Podsumowanie

Pojawi się jeszcze kilka mniej spektakularnych nowości, o których będziemy informować na bieżąco za pomocą strony statusowej. Przypominamy, że wprowadzenie osobnego serwera webowego ma na celu poprawę jakość usług oferowanych przez mydevil.net, poprzez zapewnienie większej niezawodności (separacja usług) i poprawienie ich wydajności. Mamy nadzieję, że zostanie to docenione, oraz że wybaczycie nam wszelkie utrudnienia związane z wprowadzonymi zmianami 🙂

Na wstępie pragniemy wszystkim naszym użytkownikom życzyć wszystkiego najlepszego i szczęścia w nowym roku!

Chcemy również poinformować, że z tej okazji nasza serwerownia postanowiła uruchomić nam natywne IPv6. W devil vhost public widać już 10 publicznych adresów IPv6, póki co ze standardowymi RevDNSami.

Serwer WWW Nginx słucha na pierwszym z nich, tak więc jeśli chcemy by nasza strona była dostępna również po IPv6, wystarczy dodać wpis IN AAAA w domenie, kierujący na adres 2001:41d0:1:c2b3::1. Użytkownicy, którzy mają domeny zaparkowane na naszych serwerach DNS mogą użyć polecenia:

devil dns add example.com example.com aaaa 2001:41d0:1:c2b3::1