kafi

OpenVPN (pptp/l2tp właściwie także, ale różnie to działa na różnych systemach) pozwala w konfiguracji serwera przesyłać dodatkowe trasy - czyli adresy sieci, które mają być pchane przez ten vpn. Szczególnym przypadkiem tego mechanizmu jest wypchnięcie trasy domyślnej - wtedy cały ruch klienta jest kierowany przez vpn (a tego chcesz uniknąć, więc nie stosuj push default route)

OpenVPN + push routes (ale tylko wybrane, a nie push default route).

https://sourceforge.net/projects/phpscheduleit/

Wklej komunikat błędu, który dostajesz przy odpalaniu skryptu (2).

Ja obstawiam montowanie katalogu /home z atrybutami noexec albo jakąś restrykcyjną powłokę, która nie pozwala na uruchamianie nieautoryzowanych przez administratora binarek. Tak czy inaczej - to pytanie do BOK twojego hostingu.

Nie wiem, czy/ i jaka tam wersja Apache jest, ale spróbuj czegoś takiego

AuthUserFile ...
AuthGroupFile ...
AuthName ...
AuthType ...
 
Allow from 127.0.0.1
Allow from adres.ip.serwera
require valid-user
Satisfy any

Coś na tych twoich stronach polskie znaczki się kaszanią...

Serwer DNS działa poprawnie i na zapytania odpowiada. Kwestia tylko, czy te zapytania do niego trafiają (a myślę, że nie, bo delegacja domeny w rejestrze domen nie jest tożsama z vpdns.pl. 14400 IN NS ns1.vpdns.pl. / vpdns.pl. 14400 IN NS ns2.vpdns.pl

A jak ją zmienić tak, żeby było dobrze, to dowiesz się u swojego obecnego rejestratora tej domeny.

Że niby obie firmy mieszczą się w jednym z poznańskich biurowców - http://maltaofficepark.pl/malta.php - ma świadczyć o tym, że któraś się którejś sprzedaje? Idąc tym tropem, to to, że np. Nephax i Artnet mają siedzibę w gdańskim zieleniaku, to coś niby w ich wzajemnych relacjach oznacza?

Co ma biznes-host do superhosta?

Działa. Napisz, jaki efekt chcesz uzyskać, bo mam wrażenie, że widzisz problem nie tam, gdzie on faktycznie występuje...

kfi-mac:~ konrad$ nslookup ns1.vpdns.pl 158.69.242.191
Server: 158.69.242.191
Address: 158.69.242.191#53
 
Name: ns1.vpdns.pl
Address: 158.69.242.191
 
kfi-mac:~ konrad$ nslookup ns2.vpdns.pl 158.69.242.191
Server: 158.69.242.191
Address: 158.69.242.191#53
 
Name: ns2.vpdns.pl
Address: 158.69.242.191

kfi-mac:~ konrad$ nslookup vpdns.pl 158.69.242.191
Server: 158.69.242.191
Address: 158.69.242.191#53
 
Name: vpdns.pl
Address: 158.69.242.191

Wygląda więc, że serwer DNS działa stuprocentowo poprawnie.

/post jest podwójny, bo forumowy edytor wyciął zawartość powyższego komentarza pod code, a edytować też nie pozwala.../

Mechanizm potoków jest przez crontaba jak najbardziej obsługiwany. Problem jest z backtickiem - bo jego użycie powoduje zmianę w locie wykonywanego polecenia, a tego już crontab nie analizuje (polecenia wykonuje literalnie). Czyli - póki linia poleceń jest statyczna, a dane wędrują potokami, to jest wszystko OK. Jak chce się wpływać na kształt polecenia, to już nie za bardzo.

Rozwiązaniem jest to, co napisał Archi - zakapsułkowanie tego do jakiegoś skryptu wywoływanego z powłoki - wtedy uruchomiona powłoka zinterpretuje poprawnie polecenie i je dopiero wykona.

A z innej beczki to ten plugin ma jakieś uwierzytelnienie? Czy wystawiony ryjem w internet daje wjazd wszystkim?

Tak. Musisz podać poprawny login i hasło dostępu do brokera - jak w każdym innym kliencie AMQP.

Wtedy to wykonujesz operacje w kontekście tego użytkownika, zgodnie z jego rolami i acl'kami.

Odpowiedź, czy domena może być zarejestrowana można uzyskać na kilka sposobów, które różnią się rzetelnością. Bo im bardziej rzetelna jest metoda, tym bardziej ograniczona jest dla zwykłego śmiertelnika.

Więc, można robić to przez

- odpytanie root-serwerów NS o rekordy delegacji domeny (IN NS);

- odpytanie whois i przeparsowanie odpowiedzi (zazwyczaj dla domen, które nie istnieją, odpowiedź jest nieco inna);

- bezpośrednie odpytanie rejestru domen (epp czy innym api);

- skorzystanie z API jakiegoś hurtownika domen.

Teraz komentarz do każdej z nich - dwa pierwsze pokazują tak naprawdę, czy domena jest zarejestrowana. Bo jeżeli nie jest - to wcale nie oznacza, że można ją zarejestrować. Bo nazwa może być zastrzeżona lub zablokowana przez rejestr domen lub odgórnie przez ICANN. Domena może też mieć status "premium" i być inaczej rozliczana.

Odpytanie rejestru domen jest najbardziej wiarygodne, ale nieco kosztowne (rejestry mają limity dobowe zapytań!) no i wymaga bycia akredytowanym partnerem rejestru - co wiąże się ze spełnieniem warunków (najdotkliwsze są chyba finansowe).

Drogą pośrednią może być skorzystanie z availabilityCheck jakiegoś hurtownika domen, np. eNom, Directi, Tucows, w API którego na pewno jest możliwość takiego sprawdzania. Tylko że tu też trzeba przygotować się na limity zapytań oraz dokładność (niektórzy robią pełną weryfikację, inni po łebkach sprawdzają whois).

http://pomoc.ovh.pl/BridgeClient

Tu nie ma nic o DHCP przecież

Musisz stworzyć w panelu wirtualny MAC (typ: vmware), potem przypisać do niego w tym panelu adres IP - wtedy po ustawieniu tego MAC w szczegółach wirtualnej maszyny powinna ci działać konfiguracja Bridge Client z instrukcji OVH.

"Do dnia" w całym cywilizowanym świecie oznacza, że usługa jest ważna do końca tego dnia

No właśnie nie do końca... Ten zwrot jest bardzo, ale to bardzo niejasny: http://sjp.pwn.pl/sjp/do-dnia;3027957.html

Jednak o ile w przypadku terminu "do dnia", to jeszcze możemy polemizować, to dla terminu określonego na konkretny dzień już niekoniecznie. Ale oczywiście w ramach polskiego prawa. Dyskusja jest w temacie MZone, które w Polsce nie działa, więc niekoniecznie musi tak wszystko interpretować (ale powinna to być dla nich wskazówka, że przyzwyczajeni do innego myślenia klienci mogą się "pogubić" i może warto gdzieś w dokumentacji opisać dla takich gagatków troszkę bardziej szczegółowo, jak realizowane są operacje billingowe).

a tak na marginesie to, że firmy blokują usługi w dniu ich wygaśnięcia nie powinno nikogo dziwić. To się nazywa automatyzacja

Tego nikt nie neguje. Gdyby to było określone nie jako termin płatności, a jako termin ważności usługi (czy coś w ten deseń) do dnia xx.yy.zzzz, to jeszcze można by dyskutować, czy płatność uiścić należy do świtu, czy zmierzchu. Jednakże jeżeli ktoś podaje jawnie "termin płatności", to pomimo tego, że usługa wygasła dzień/dwa/więcej przed, nie powinien jej blokować przed jego formalnym upływem z powodu braku płatności. MZone nie jest polskim podmiotem, a w regulacjach na wyspach się nie orientuję, ale w przypadku firm polskich, które obowiązuje przestrzeganie prawa w PL, to termin ustalony w dniach kończy się z końcem dnia, nie jego początkiem (art. 111 k.c. i jego okolice). Czyli termin płatności 5.04. oznacza 5.04. godz. 23:59; czy to się komuś podoba, czy nie

Transit to raczej taka "kwarantanna" po usunięciu domeny.

W przypadku domen .de skontaktuj się z nowym rejestratorem - jeżeli będzie kumaty, to będzie ci w stanie pomóc (najlepiej szukaj takiego, który jest partnerem DENIC, a nie jakimś resellerem). Procedura pokazana jest na obrazku https://www.denic.de/fileadmin/public/documents/authinfo/authinfo2_beantragung_EN.png

Źródło: https://www.denic.de/en/domains/de-domains/provider-transfer/how-to-generate-and-store-an-authinfo/

Dla domen .eu - https://www.eurid.eu/pl/abonenci-domen-eu/transfer-your-eu-domain-name/wniosek-o-kod-autoryzacyjny

Szukaj linków zawierających słowo extranet (jeżeli masz dostęp do maila abonenta domeny) lub wnioskować (jeżeli nie masz).

Dla innych domen to z tym obowiązkiem bym był ostrożny. Ale najprościej uderzyć do registrara domeny wg bazy WHOIS (zapewne będzie to EuroDNS) i zażądać wydania authinfo z pominięciem partnera.

Tylko ile ludzi kupuje wersje BOX za dość spore pieniądze a ile kupuje tańszą wersje OEM?

Procentowo pewnie dokładnie tyle, ile kupuje bilety komunikacji miejskiej na okaziciela, a nie imienne.

Z jakiegoś powodu te umożliwiające swobodną rotację są droższe od tych limitowanych do "osoby" - czy to bilety, czy to licencje Windowsa.

Tak. W konfiguracji serwera musisz zdefiniować katalog client-config-dir, w nim stworzyć dedykowany plik konfiguracyjny dla tego jednego wybranego klienta (nazwa musi być tożsama z CN jego certyfikatu), w nim zawrzeć dyrektywy wypychające gateway i serwery DNS, no i ustawić na serwerze SNAT/maskaradę z interfejsu wejściowego tap z adresu IP źródłowego odpowiadającego adresowi owego klienta do interfejsu docelowego eth0 (czy tam jak się zwie główny wyjściowy). Następnie na kliencie odblokowujesz otrzymywanie tras (jeżeli wcześniej je tam wyłączyłeś) i powinno działać.

Dawno temu robiło się zabieg mający na celu rozrzucenie "zapełniających się" ścieżek takich jak /tmp czy /var/log na oddzielne partycje, żeby upewnić się, że nie zajadą dysku na 100% i będzie możliwe zalogowanie się do serwera.

To jest tylko jeden z aspektów...

a w najgorszym przypadku quota od limitowania konkretnych ścieżek

quota limituje raczej udziały użytkownika na partycji, a nie konkretne ścieżki. Więc ciężko np. takiemu mysql'owi ograniczyć, żeby do DATADIR mógł zapisywać, a do logów już niekoniecznie. Druga sprawa - po co zmuszać system do ciągłego liczenia i przeliczania owej quoty, skoro można robić taki "bezpiecznik" na poziomie systemu plików (bo to, że od rotacji logów jest logrotate, to nie wątpię - ale co w momencie, gdy interwał rotacji jest zbyt mały i w ciągu kilku minut plik logów urośnie do wartości monstrualnej?).

Inne aspekty to ustawianie różnych flag montowania dla różnych partycji - przykładowo noexec, nosuid, nodiratime - bo po co ciągle aktualizować czas ostatniego dostępu do katalogu z logami czy po co wykonywać binarki z loga / tmp?

Ale fakt faktem - do większości standardowych zastosowań wygodniejsze będzie wszystko na jednej partycji.

Czemu nie na LVM?

LVM wbrew pozorom spowalnia operacje I/O. Więc jeśli nie ma uzasadnionej potrzeby jego stosowania, to warto sobie go darować.

A co do układu partycji - to ciekawym jest jeszcze układ

0 - /boot - troszkę miejsca

1 - swap - 2GB (więcej nie ma sensu - Archi wyżej napisał czemu)

2 - / - reszta miejsca na dysku

Ma on taką zaletę, że /boot jest na początku dysku (więc bootowanie nie będzie się dziwnie zachowywać na żadnej konfiguracji), a wtedy gdy będziesz chciał rozszerzyć dysk, to po prostu:

1. (a) zwiększysz rozmiar pliku VHD w przypadku wirtualizacji (b) skopiujesz go 1:1 na nowy, większy w przypadku dysku fizycznego;

2. zwiększysz rozmiar partycji root (dzięki temu, że jest ostatnia, to wystarczy tylko zmienić wskaźnik końca;

3. zwiększysz rozmiar systemu plików.

Gdy na końcu dysku będzie swap (a jeszcze gorzej, gdy inna partycja), taka operacja będzie nieco cięższa do wykonania.

I tak, twierdzę że korzystanie z przestarzałej technologii, która nie jest już rozwijana mając nowsze i dużo lepsze alternatywy to czysta ignorancja lub skrajne lenistwo, często połączone z obawą przed technologią i głupotą.

To, co dla ciebie jest ignorancją czy skrajnym lenistwem to nierzadko w rzeczywistości... świadoma analiza ryzyka.

Jeżeli współczynnik ryzyka będzie bardzo mały (np. prawdopodobieństwo małe + wpływ mały), to może ono zostać świadomie zaakceptowane, bo biznesowo koszt zmniejszenia ryzyka będzie znacznie większy, niż wartość potencjalnych strat.

Próbuję sobie to przetestować (bez sępienia vouchera - po prostu płacąc za to).

Na początku przy rejestracji zostawiłem domyślną kwotę (4zł). Konto cloud po jakimś czasie się założyło.

Próba utworzenia instancji w lokalizacji DE zwracała błąd - spróbuj ponownie później.

Zmieniłem DC na Francję, spróbowałem utworzyć instancję. Mieliło dosyć długi czas, po czym w powiadomieniach pojawił się bardzo ładny komunikat (patrz załącznik).

Dziś spróbowałem ponownie w DE. Udało się, instancja się utworzyła, po czym... przyszedł mail o takiej treści:

Szanowny Kliencie,

Twój stan konta pre-paid dla usługi ARUBA Cloud C00052965 (login:FPL-48179) został wykorzystany.

Usługa została zawieszona w dniu 23.3.2016 13:19:25.

Jeśli nie wykonasz doładowania stanu konta, usługa zostanie całkowicie usunięta w dniu 8.4.2016.

Proszę złożyć zamówienie doładowania z sekcji konta klienta.
Po doładowaniu stanu konta wystarczającą kwotą, usługa zostanie przywrócona.

Życzymy miłego dnia.

AlphaNet sp. z o. o.

Administracja klienta: http://klient.arubacloud.pl

Portal wsparcia: http://support.arubacloud.pl [08:00 - 18:00 dni robocze]
Telefon: (+48) 032 441 63 46 [08:00 - 18:00 dni robocze]
Fax: (+48) 032 750 87 06

Email: info@arubacloud.pl [08:00 - 18:00 dni robocze]

Zastanawiam się zatem, jak to jest, że instancja, która ma działać za te cztery złote miesiąc, została z automatu niby zablokowana i ma być usunięta za dwa tygodnie.

Wniosek: dla mnie pierwsze wrażenie totalnie na minus.

Bo skoro na samym początku takie kwiatki wychodzą, to cóż...