Skip to main content

Congratulations Dominik 'rathann' Mierzejewski on winning FESCo seat!


- 2016-07-26T05:28:54+0000 - Updated: 2016-07-26T05:28:54+0000
Congratulations Dominik 'rathann' Mierzejewski on winning FESCo seat!
Shared with: Public
- 2016-07-26T06:22:32+0000
Does he do his do diligent and research before making decisions or does he "parrot ack" like majority of FESCo members do and have done historically?
- 2016-07-26T07:35:41+0000
He seem reasonable for me. I voted for him because he is not docker-crazy like the rest of the candidates. I hope to speak with him next week.

"Pełnia szczęścia". Świetna sztuka, Teatr Wybrzeże dostarcza :-)


- 2016-07-23T20:51:22+0000 - Updated: 2016-07-23T21:30:04+0000
"Pełnia szczęścia". Świetna sztuka, Teatr Wybrzeże dostarcza :-)FAKTORIA Pruszcz Gdański
Address: Zastawna, 83-000 Pruszcz Gdański, Poland
Shared with: Public
- 2016-07-24T14:49:18+0000
Z tej recenzji to najbardziej zgadzam się z komentarzami pod nią.
Nas sztuka wciągnęła, czas minął niezauważenie. Podobało mi się, że aktorzy nie wydzierali się na siebie, zaskoczył mnie twist, a po wszystkim było o czym porozmawiać.

Finally got budget approval for systemd.conf 2016 trip. So I got the ticket. ...


- 2016-07-22T11:51:31+0000 - Updated: 2016-07-22T11:51:31+0000
Finally got budget approval for systemd.conf 2016 trip. So I got the ticket. Now I need Berlin accomodation only!
Originally shared by systemdWe're happy to announce this year's systemd.conf taking place Sept. 28th - Oct. 1st, once again in Berlin. You can get your tickets and find out about sponsorship opportunities here: https://conf.systemd.io/

See you there!

| systemd.conf 2016

Shared with: Public

Rejestr na PP


Lokalny oddział Poczty Polskiej ma niezłą innowację: rejestr przesyłek nierejestrowanych. Informacje o normalnych przesyłkach poleconych trzymane są w systemie komputerowym. Natomiast nierejestrowane spisywane są przez pracowników w zeszyciku…

Zamiast sprzedaży rajstop, resorówek i wprowadzania bezpłatne WiFi mogłaby ta firma zająć się dostarczaniem przesyłek zamiast tylko roznosić awizo. Zmniejszyło by to kolejki w wiecznie zatłoczonych oddziałach.

Oh well. It's been a year, and I am completely unable to select a dozen o...


- 2016-06-16T08:58:45+0000 - Updated: 2016-06-16T08:58:45+0000
Oh well. It's been a year, and I am completely unable to select a dozen of the most representative photos. It is impossible to compress Iceland into less than two hundred.
Few of them are even wallpaper-worthy.

2015-06 Icelandic Countryside

Shared with: Public
- 2016-06-16T09:07:49+0000
You need to revisit when there is actual summer ;)

Migracja do bcache


Natywnego użycia SSD jako pamięci podręcznej (coś jak ZIL czy L2ARC) w btrfs się nie doczekałem, mimo planów sprzed 4 lat. Postanowiłem więc zastosować bcache, który wydaje się już stabilne (miało na dorośnięcie sześć lat), chociaż jego autor wpadł ostatnio na dziwny pomysł przerobienia go na system plików.

bcache ma jeden spory minus: wymaga specjalnego sformatowania dysku, który ma przyspieszać (taki dm-cache potrafi się dołączyć na żywca). Trzeba więc jakoś przenieść dane.

Stan wyjściowy

Celem była sensowniejsza konfiguracja pamięci masowej na moim domowym serwerku. Jest to maszynka wszystkomająca, czyli jest tam mój katalog domowy, archiwum i serwer poczty, bazy danych, backupy zdjęć z wyjazdów, skany dokumentów, blog, stronka www, dane multimedialne, maszyny wirtualne i przeróżne inne dane. Do tej pory zaorganizowane tak:

/dżogstaff/2016.05.25-stan-wyjściowy.svg

Na dysku SSD trzymałem większośc /var i katalogi domowe. Nie widzę finansowego sensu trzymania wszystkiego na SSD.

Skorzystanie z bcache to wetknięcie w tę jengę kolejnego klocka. A nawet dwóch. Pojawiają się dwie możliwości umieszczenia nowej warstwy.

Opcja 1 – bcache na szczycie

Czyli tuż pod systemem plików:

/dżogstaff/2016.05.25-opcja1.svg

Zalety:

  • cache nie jest szyfrowany, więc powinno być szybciej

Ale również wady:

  • cache nie jest szyfrowany; co prawda wydaje mi się, że będzie tam sieczka, ale zawsze jest ryzyko odzyskania mniejszych plików

Opcja 2 - bcache na spodzie

Umieszczenie warstwy bcache tuż nad dyskami wyglądałoby tak:

/dżogstaff/2016.05.25-opcja2.svg

Zalety:

  • układ wydaje mi się bardziej estetyczny, logiczniejszy

Wady:

  • więcej ruchomych elementów przy migracji – trzeba jeszcze zadbać o LUKSa na dm-crypt

W obu opcjach korzystam z tego, że jeden cache może obsługiwać dowolną liczbę urządzeń. Dzięki temu nie musiałem dzielić mojego SSD na kolejne partycje.

(opcji trzeciej miszmasz na krzyż nie ma co omawiać)

Plan i migracja

Planowałem wykorzystać właściwości RAID1 i migracji dokonać poprzez:

  1. oznaczenie jednego z dysków jako popsuty

  2. przeformatowanie pod bcache, przeLUKSowanie tego dysku

  3. dołączenie gotowego dysku z powrotem do puli btrfs

  4. odbudowa RAID1

  5. powtórka zabawy z drugim dyskiem

  6. przegranie /var i ~

  7. podpięcie zwolnionego dysku SSD jako cache

Zestawiłem sobie na maszynie wirtualnej identyczną konfigurację i zacząłem testy. Poległem na punkcie 1… btrfs nie ma możliwości grzecznego popsucia dysku (skandal!). Można co najwyżej wyrwać dysk z maszyny i szybko wyczyścić.

Nie chcąc tracić za dużo czasu (jakby coś nie poszło, to odwinięcie danych z backupu trochę jednak trwa), zacząłem szukać innej drogi. Wszystkie luźne dyski w pracy użyłem do postawienia małego klastra Ceph (fajna zabawka swoją drogą), nie miałem pomysłu skąd wziąć tymczasowe kilka terabajtów.

Postanowiłem sprawdzić konwerter o jakże nudnej nazwie blocks. I to był strzał w dziesiątkę. blocks potrafi przesunąć nagłówek LUKS i umieścić przed nim nagłówek bcache, nie ruszając danych. Kilka testów i dwa rebooty później miałem przearanżowaną pamięć masową zgodnie z opcją 2.

Zrobione

lsblk zeznaje:

└─sda3                                            93.8G   part
  ├─bcache0                                        5.5T   disk
  │ └─luks-142b6130-853c-4dab-ab7b-a102e7d71388    5.5T   crypt /
  └─bcache1                                        5.5T   disk
    └─luks-4e5418e6-fa2c-47b3-a4be-1b045d593a5a    5.5T   crypt

A wykres wykorzystania pamięci podręcznej wygląda dosyć optymistycznie:

/dżogstaff/2016.05.24-bcache_hit.png

I jakiś taki porządek jest.

Własny, prywatny mirror Fedory


Linuksowe dystrybucje od lat polegają na sieci serwerów lustrzanych (mirrorów) aby dotrzeć do użytkowników. Taka Fedora ma półtorej setki miejsc, z której można pobierać pakiety. Stworzenie prywatnego mirrora dla swoich systemów czasem się przydaje i na szczęście jest łatwiutkie.

Zgłoszenie w Fedorze

Pierwsze co, to wybieramy, skąd będziemy pobierać pakiety. Z oficjalnych serwerów Fedory mogą ciągnąć tylko publiczne serwery lustrzane – nam zostaje ściąganie właśnie z któregoś z nich. Wybieramy co nas interesuje i ustawiamy periodyczne wywołanie rsynca.

Teraz informujemy infrastrukturę Fedory, że mamy prywatny serwer lustrzany. Dopisujemy zakresy sieci, z których komputery mają korzystać z naszego mirrora [*]. Co jakiś czas uruchamiamy skrypt, który wysyła spis zawartości naszego prywatnego serwera lustrzanego. Serwery publiczne są przeczesywane automatycznie przez Fedorę.

Konfiguracja stacji klienckich

Nic. Od tej pory wszystko dzieje się automatycznie! A to dlatego, że każda fedora aktualizując się, najpierw pyta serwery dystrybucji o listę mirrorów. Dystrybucja widząc połączenie przychodzące z „naszych” sieci jako główny serwer lustrzany podaje nasz prywatny mirror. Wysłana wcześniej lista zawartości pozwala też wykluczyć mirror z odpowiedzi, jeśli nie zawiera pakietów dla odpowiedniego wydania i architektury.

Oczywiście zapytania z innych sieci (nie podanych w liście naszych) nigdy w odpowiedzi nie dostaną adresu naszego prywatnego mirrora.

Taka zero-konfiguracja po stronie klienta działa naprawdę fajnie. Każda wirtualka, kontener, komputer gościa czy nawet proces budowania pakietu w środowisku mock automatycznie korzysta z pakietów przechowywanych lokalnie.

Intel's <i>bootutil32</i> doesn't work with recent (like few years re...


- 2016-04-25T07:39:37+0000 - Updated: 2016-04-25T07:39:37+0000
Intel's bootutil32 doesn't work with recent (like few years recent) kernels with CONFIG_STRICT_DEVMEM=y:

[51709.964489] Program bootutil32 tried to access /dev/mem between ea020000->ea040000.

Dear lazyplus, does anyone know a different way to flash iPXE into Intel gigabit NICs?
Shared with: Public
- 2016-04-25T09:46:27+0000
Dont you just need a dos based stick that runs the bootutil from intel and flash it from there?
- 2016-04-25T13:11:52+0000
The junk I'm using for playing doesn't support USB boot.
I would also prefer to do everything under Linux.
- 2016-04-25T13:28:12+0000
When it comes to firmware updates and Linux you pretty much are royally screwed from manufacturers point of view. You might manage with flashrom utility if the card is supported if not it's back to bootable cd/usb stick with relevant .exe files
- 2016-04-28T10:38:18+0000
There is flashrom (http://ipxe.org/howto/romburning/flashrom) which seem to work. With nicintel_spi driver.

Tak się nie powinno robić samochodów


Jakiś czas temu chwaliłem Teslę za ogarnięcie softwareowej części samochodu i połączonej infrastruktury. Różowo jednak nie jest, bo strona sprzętowa wydaje się być zrobiona z masy papierowej, delikatnej jak skorupka jajka.

Zimą trzeba na Model S chuchać i dmuchać, myć co najmniej raz dziennie:

If salt has been used on the highways (such as during winter months), thoroughly rinse all traces of road salt from the underside of the vehicle.

Najlepiej ręcznie, bo myjnia automatyczna ze szczotkami wchodzi w konflikt z gwarancją:

If washing in an automatic car wash, use “Touchless” car washes only. These car washes must have no parts, such as brushes, that can touch Model S. Using any other type of car wash could cause damage that is not covered by the warranty.

I bez chemii na felgi, bo rozpuści.

Samochód jest zrobiony z tak cienkiej i delikatnej blachy, że do zamykania maski trzeba używać obydwu rąk i naciskać w ściśle wyznaczonych miejscach (narysowanych w instrukcji). Tesla Model S, samochód który można powyginać jedną ręką:

Do not close the hood with one hand. Doing so applies concentrated force in one area and can result in a dent or crease.

Wracając do zimy – zdarzały się u nas porządne, kiedy zamarzały słabsze płyny do spryskiwaczy. A co z autem?

Do not expose Model S to ambient temperatures above 140° F (60° C) or below -22° F (-30° C) for more than 24 hours at a time.

Na szczęście mroźne miesiące się kończą i przychodzi wiosna. Przy zmianie opon na letnie trzeba pamiętać o zablokowaniu aktywnego zawieszenia, bo może zabić:

If you do not disable Active Air Suspension, Model S can attempt to self-level, causing serious damage, bodily injury, or death.

Na koniec pozytywna informacja. Jeśli uda nam się nie pognieść autka, to uzupełnianie płynów jest ograniczone do minimum:

Model S has only one reservoir into which you can add fluid. This is the washer fluid reservoir under the front trunk.

Może w ramach liftingu Tesla zastosuje wytrzymalszą blachę i lakier?

Schronisko dla kart SD


Aktualizacja 2017-02: Kolega na reddicie wyżalił się z tym samym problemem. Poradzono mu… wyłączyć telefon i włączyć ponownie. I co? I po tym działa. WTF Android?


W Androidzie 6.0 pojawiła się opcja sformatowania karty SD w sposób rozszerzający wewnętrzną pamięć masową telefonu. Nazywa się to adoptable storage i działa(?) dosyć dziwnie.

Karta tak spreparowana przestaje być dostępna przez np. AirDroid. Niby jest podmountowana w /mnt/expand, ale wedle dokumentacji wgląd mają tam tylko aplikacje systemowe. Podłączenie przez kabelek (MTP) też nie pokazuje katalogu. Można tam przenieść enigmatycznie określone dane korzystając z opcji Przenieś aplikacje i dane w ustawieniach pamięci masowej, ale normalnego zarządzania i wgrywania np. audiobooków z laptopa nie da się zrobić.

Oczywiście istnieje możliwość rozszyfrowania karty po jej przełożeniu do komputera, ale poziom rzeźby wykracza poza wygodne korzystanie z telefonu. Wróciłem więc do karty sformatowanej po staremu – VFAT zamiast dm-crypt+ext4.

Na marginesie, jakby ktoś się dał nabrać na obietnice Chińczyków z Lenovo/Motorola że będą wypuszczać aktualizację do telefonów na bieżąco… bullshit. Aktualizację Moto G do Androida 5.0 ogłosili(!) we wrześniu 2014, a tak naprawdę pojawiła się w lutym 2015. Android 6.0 wyszedł w październiku 2015, na Moto G pojawił się pod koniec marca 2016. Pół roku za każdym razem, dystrybucje linuksowe w tym czasie całe nowe wersje są w stanie opracować i wydać.

Telefon kupiony w sklepie, więc żadnego zasłaniania się opóźnieniami po stronie pośrednika/telekoma być nie może.

Mysteriously flapping network connection


Fool me once, shame on you. Fool me twice, and I will write a blogpost to remember.

For a few days I've been experiencing intermittent networking problems. Every couple of minutes iSCSI and FCoE connection seemed to break for a brief moment. This made filesystem quite unhappy. I've added another path to iSCSI target, over legacy IPv4, but it didn't help. And because all paths were disappearing at the same moment, multipath device was failing, too.

So, iSCSI-over-IPv6, iSCSI-over-IPv4 and FCoE were crumbling. Clearly, the network was at fault (as it always is!). Then it hit me. I have seen a bug like this before. It manifested a bit different because of a different driver (r8169 vs tg3), but even without hints in dmesg I've recognized the problem.

You see, ethernet port at gigabit speed is quite powerhungry. Limiting speed to 100MBps can reduce power draw, especially with multi-port and multi-gigabits NICs. This fact is utilized by tuned utility. If you put tuned into powersave profile – like my misbehaving station was – and you have dynamic_tuning = 1 in configuration file…

During idle periods, tuned dropped my NIC into one hundred megabits speed. When bandwidth usage rose, tuned flipped the network card to gigabit speed. Brief moment of layer-1 renegotation was enough to disturb the connection to the storage target.

Disabling dynamic tuning restored the network to rock-solid state instantly.

Intermedium


Tak… Jogger się kończy, więc trzeba się przenieść. Mój pierwszy post napisałem w czerwcu 2003, więc jestem tutaj praktycznie od początku. Zaczęło się od testowania ekg2, które wówczas rozwijałem. Potem pisałem trochę o rzeczach życiowych (w tym uczelnia), trochę o technicznych, trochę o ciekawostkach. Świetna społeczność joggerowa towarzyszyła mi ponad dekadę. Teraz idę na swoje.

W czasie weekendowego researchu spodobał mi się generator Nikola. Jest w miarę przejrzysty, wygląda na rozszerzalny, społeczność na IRCu jest bardzo pomocna i co ważne: jest spaczkowany w Fedorze. Trochę grzebania w konfiguracji, trochę poprawek w skrypcie https://gist.github.com/malpka/8273337 i działa. Udało się zachować URLe do archiwalnych wpisów, adres bloga https://enotty.pipebreaker.pl się nie zmienia, więc przepięcie powinno być prawie niezauważone.

Prawie, bo niestety nie dało się bezboleśnie przenieść największej zalety Joggera – komentarzy. Archiwalne podoklejałem pod wpisami. Nowe komentarze: tutaj trzeba skorzystać z zewnętrznego dostawcy. Wybrałem komentarze Google+. Nie do końca jeszcze ogarniam, jak mają działać, ale to się dotrze w praniu.

Następnej zmiany nie planuje wcześniej niż za kolejne 13 lat. ;-)


Archived comments:

Remigiusz 'lRem' Modrzejewski 2016-02-23 13:57:46

A jest już oficjalne API do podpinania komentarzy G+, czy nadal jakaś rzeźba na niesupportowanym haczyku który może jutro zniknąć?

zdz 2016-02-23 15:27:49

Z Google to nawet supportowane rzeczy mogą jutro zniknąć. Ale na pytanie konkretnie Ci nie odpowiem, bo jeszcze nie wiem na jakiej zasadzie to jest w ogóle zorganizowane. Strony supportu googla (do których odnosi dokumentacja pluginów G+ comments do różnych platform blogowych/CMS) wyglądają na przeterminowane. Jak przepnę domenę to zadziała albo nie ;)

Tak się powinno robić samochody


W weekend w końcu znalazłem trochę czasu na obejrzenie DEF CON 23 - Marc Rogers and Kevin Mahaffey - How to Hack a Tesla Model S. Potwierdziło się to, co czytałem wcześniej. Tesla naprawdę porządnie robi samochody.

Security IT mają zrobione bardzo dobrze zarówno wewnętrznie — izolowane podsieci CAN i infotainment z „firewallem” w postaci modułu gateway, szyfrowanie prawie wszędzie, użycie SSH do komunikacji między komponentami — ale również zewnętrznie: OpenVPN z dokładnym sprawdzaniem certyfikatów (keyUsage) itp. W przypadku „zabicia” elektroniki przez atakującego, samochodem nadal można kierować i działają hamulce.

Co prawda używają starego Ubuntu i było kilka drobnych niedoróbek, ale plusem Tesla Motors jest też sprawny system patchowania. I ekipa ludzi, którzy biorą IT Security poważnie. Poważniej, niż niektóre biznesy z którymi współpracowałem.

Prezentacja warto obejrzeć, sam chętnie bym zobaczył wycieczkę po serwerowni Tesla Motors i posłuchał więcej: jak zarządzają certyfikatami dla każdego samochodu, jaką mają infrastrukturę sieciową, jak przechowują i obrabiają telemetrię itp.


Archived comments:

sprae 2016-01-28 01:47:44

Dziękuję, też zobaczę.