W zasadzie większość z nas ma stały adres IP, najczęściej zmienia się tylko w przypadku gdy nasz router ponownie nawiązuje połączenie z usługodawcą (ISP). W takiej sytuacji, np. w warunkach domowych, aż pragnie się wystawić na świat np. album zdjęć lub inne rzeczy, których nie chcemy umieszczać bezpośrednio na serwerach firm trzecich (w tzw. chmurze). Tylko jak przekazać link innym? Przecież za każdym razem nie będziemy podawać czegoś w stylu http://125.130.125.2. Po pierwsze ponieważ jutro możemy mieć już inny publiczny adres IP nadany przez ISP (np. modem się zrestartował), a po drugie łatwiej zapamiętać http://home.domena.pl .

DDNS – zewnętrzni usługodawcy

Skonfigurowanie subodmeny to rzecz prosta. Pozostaje inna kwestia – jak zautomatyzować proces, aby adres home.domena.pl zawsze kierował na naszą domową maszynę? Nic prostszego – możemy wykorzystać DDNS / DynDNS / dynamiczny DNS. Proces polega na tym, że wydzielamy z naszej domena.pl subdomenę, która ma inny TTL (czas odświeżania) i zarządzamy samą domeną oddzielnie (co też umożliwia lepszą kontrolę pod względem bezpieczeństwa). Możemy wykorzystać darmowe serwisy oferujące usługę DDNS, gdzie dostaniemy subdomenę w ramach ich domeny. Z naszej strony pozostaje ustawić cykliczną operację (cron) na wysłanie zapytania do API celem aktualizacji wpisu DNS dla subdomeny.

Taką usługę oferuje chociażby FreeDNS. Rejestracja jest bardzo prosta, po wszystkim pozostaje nam wywołanie przekazanego URI z tokenem naszej subdomeny w naszej sieci lokalnej (router/serwer/etc):

[~] $ curl https://sync.afraid.org/u/CyTXMbtq5cPnLjEg5vKHTPDE/
Updated demo.freshdns.com from 107.170.238.X to 50.23.197.94

Jeśli posiadacie własną domenę i korzystacie z gotowego panelu do zarządzania domeną to często jest możliwość skonfigurowania bezpośrednio tam DDNS. Taką usługę oferuje chociażby OVH.

DDNS – własne rozwiązanie

Ale może niektórzy z Was lubią posiadać większą kontrolę nad domeną (specyficzne rekordy) niż oferuje firma, w której opłacacie domenę. Posiadacie np. własną instancję BIND, gdzie trzymacie kilka domen (prostą konfigurację BIND opisałem w 2010 roku) i chcielibyście wykorzystać ten serwer nazw do DDNS. Sam tak właśnie pomyślałem, gdy okazało się, że na jednym z interfejsów zewn. posiadam dość zmienną adresację.

DDNS – modyfikacja w BIND

Zacznijmy od zmiany w samym BIND. Powiedzmy, że posiadamy domenę domena.pl i jej strefa u nas wygląda następująco:

$TTL 86400
$ORIGIN domena.pl.
@ IN SOA dns1.domena.pl. root.domena.pl. (
        2010111801 ;; serial
        2H         ;; refresh
        1H         ;; retry
        7D         ;; expire
        1D         ;; TTL
        )
@               IN      NS      dns1.domena.pl.
@               IN      NS      dns2.domena.pl.

@               IN      MX      10 mail.domena.pl.

@               IN      A       XXX.XX.XX.X
dns1            IN      A       XXX.XX.XX.X
dns2            IN      A       YYY.YY.YY.Y

www             IN      CNAME   @
mail            IN      CNAME   @
ftp             IN      CNAME   www

I gdy chemy dodać dodać naszą domową/lokalną subdomenę tworzymy dodatkową pozycją:

home            IN      A       ZZZ.ZZ.ZZ.Z

Ale w naszym przypadku dodajemy home.domena.pl z informacją, że jest zarządzana osobno:

home            IN      NS      dns1.domena.pl.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Pierwszy artykuł na blogu Hello World! pojawił się 14 września 2009 roku. Od tamtej pory popełniłem 630 artykułów (z dzisiejszym będzie 631) – jedne lepsze, inne gorsze. Część postów była celowo kontrowersyjna, część napisana na kolanie, pojawiło się kilka konkursów, w których rozdawałem książki, artykuły o Windows Azure pozwoliły mi pojechać do Las Vegas na konferencję Microsoftu, a dzięki podjęciu kilku tematów, otrzymałem wiele interesujących ofert współpracy. Później przyszła niemoc twórcza i na blogu pojawiały się luźne tematy, związane z muzyką, podróżami i innymi przyziemnymi... [[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Dobrych kilka lat temu, lubiłem zaglądać na polskie strony poświęcone tzw. współczesnym technologiom, ponieważ oferowały one coś więcej niż suche fakty i oderwane od rzeczywistości „testy”. Dosyć często można było znaleźć rzeczowa opinię, kompletny test usługi, wartościowe komentarze do opisywanej usługi. Taki stan rzeczy utrzymywał się dosyć długo i spośród dostępnych źródeł informacji na temat nowych technologii, miałem co najmniej kilkanaście polskich. Do czasu. W mediach tzw. mainstreamu zaobserwowałem to już dawno i liczyłem, że nigdy nie trafi do blogów o tematyce IT.... [[ This is a content summary only. Visit my website for full links, other content, and more! ]]

W moim pierwszym artykule o Docker pokazałem wam jak przygotować podstawowy kontener, który zawiera php. mysql oraz apache. Trochę mi się oberwało, że skoro używam kontenerów to wypadałoby na każdy serwis postawić oddzielny kontener i w razie potrzeb przełączać się między kontenerami by uzyskać różne środowiska testowe bez konieczności większych zmian w konfiguracji. Ok, nauka zapamiętana... Dziś pokażę więc wam jak stworzyć kilka różnych kontenerów, każdy z jedną usługą, a następnie połączę to wszystko w jedno piękne środowisko testowe, w którym możemy odpalać naszą aplikację zarówno na php5 jak i php7

W poprzednim artykule (Docker - podstawowy kontener) opowiedziałem Wam o moich pierwszych przygodach z Dockerem i linuksowymi kontenerami. Jedną z zalet, jaką wszyscy podają, jest brak wirtualizacji (a co za tym idzie duża oszczędność zasobów) w porównaniu do Vagrant, który to używa właśnie wirtualizacji, choćby przy pomocy VirtualBox. Gdy się tak zagłebiałem w świad Dockera, przypadkiem natrafiłem na wtyczkę do Vagrant, która to zamiast np. VirtualBox używa własnie LXC - vagrant-lxc

W arcie tym postaram się wam szybko pokazać jak przygodować swój pierwszy kontener do pracy z projektem lub projektami. Nie będę się rozpisywał czym jest docker, gdyż w necie znajdziecie całą masę wyjaśnień pisanych przez osoby bardziej doświadczone w temacie niż ja. Ja na szybko powiem tak: Docker to narzędzie, które pozwala stworzyć kontenery, które dostarczają środowisko pracy, ale jednocześnie są odseperowane od systemu głównego oraz od innych kontenerów, dzięki czemu możecie sobie robić z danym kontenerem co wam się żywnie podoba i nie wpłynie to w żaden sposób na wasz główny system, czyli np. możecie zainstalować sobie na próbę php7 w kontenerze i nie martwić się, że szlag wam trafi wasze inne projekty chodzące na php5. Coś podobnego daje wam również Vagrant, ale Vagrant tworzy Virtualne Maszyny i jest przez to wolniejszy oraz zużywa więcej zasobów.

Całkiem niedawno puściłem takiego oto tweeta:

Look mom, I just made myself a TODO "system". pic.twitter.com/Tjm6J2Mwhe

— Radek Benkel (@singlespl) December 1, 2014

Jedna z odpowiedzi sugerowała, że żartuję i robię sobie przysłowiowe jaja. Haczyk w tym, że wcale nie. Pokażę Wam w jaki sposób mam zorganizowane zarządzanie pocztą – a co za tym idzie – jak system TODO oparty na mailu idealnie się w to wpasowuje.

Dla tych z Was, którzy czytali „Getting Things Done” Allena metody te nie będą pewnie nowością. Mi ta książka nie podeszła, ale podświadomych inspiracji nie wykluczam :).

Zasada #1: Rzeczy w skrzynce odbiorczej czekają na akcję.

W pewnym momencie zdałem sobie sprawę, że spora większość maili które otrzymuję wymaga jakiejś akcji:

• faktura – płacę + drukuję/archiwizuję/wysyłam księgowej
• pytanie o wykonanie usługi – odpowiadam/przygotowuję ofertę
• komentarz na GitHubie – odpowiadam (pytania bez odpowiedzi to zło)
• mail do kumpla z nowym popularnym video – odpowiadam, najczęściej jest to „widziałem” (chyba za dużo czasu spędzam na YT)
• zaproszenie na Li/FB – akceptuję (znajomi) lub odrzucam (ludzie których nie znam/rekruterzy którzy nawet nie przeczytali profilu)
• newsletter z pointer.io – dorzucam ciekawe artykuły do Pocketa
• potwierdzenie nadania przesyłki – zostawiam do czasu aż do mnie dotrze (czasami zamawiam sporo rzeczy i czasami można przypomnieć sobie o jednej po miesiącu)
• etc.

Nieistotne jest kiedy zajmiecie się danym mailem. Możecie korzystać z zasady „jeśli coś zajmuje mniej niż 5 minut, to zrób to od razu”, możecie zostawiać na potem. Ważny jest fakt, żeby leżał w skrzynce dopóki się nim nie zajmiecie.

Zasada #2: Jeśli coś nie wymaga akcji, wylatuje ze skrzynki odbiorczej.

Oraz jej rozwinięcie: mail na którego odpowiedziałeś i/lub nie wymaga od Ciebie akcji jest od razu archiwizowany/usuwany.

Ja usuwam – kosz najczęściej opróżniany jest po 30 dniach, tak więc jeśli dyskusja będzie się ciągnąć, to i tak będę miał dostęp do tego maila. Jeśli nie, to zakładam że nadawca przy następnym mailu dołączy kontekst.

Zasada #3: Do skrzynki odbiorczej trafiają także maile wychodzące.

Wyobraźcie sobie sytuację, że reklamujecie jakiś produkt wysyłając maila do sprzedawcy. Czasami można zapomnieć o tym, że sprzedawca miał nam odpisać. Jest na to prosty sposób – podczas pisania maila dodajcie siebie do BCC – tym sposobem mail trafi do skrzynki odbiorczej i nie zapomnicie. A dodatkowo dzięki temu, że przy każdym mailu widnieje data wysłania będziecie widzieć jak długo zajęła mu odpowiedź.

Jeśli długo nie dostajecie odpowiedzi, to już Wasza decyzja co zrobić z tym mailem dalej – jeśli odpuszczacie sprawę, to maila kasujecie albo nadajecie mu specjalną etykietę – patrz zasada nr #4.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...