New images are available for the arm64 M1 platform:

• AlmaLinux 9.0 arm64

• Ubuntu 22.04 arm64

https://app.vagrantup.com/marcinbojko/

https://github.com/marcinbojko/vagrant-boxes

Enjoy!

https://github.com/marcinbojko/linux_mint

Bez wątpienia – Chocolatey (https://chocolatey.org/) jest doskonałym zarządcą pakietów dla systemu WIndows – zwłaszcza w instalacjach DesiredStateConfiguration. Trochę przytłacza mnogość sposobów instalacji pakietów (w zasadzie, każdy pakiet potrafi być oddzielnym kawałkiem kodu), jednak rekompensuje to z nawiązką ich niskim skomplikowaniem.

Owszem, sporo pakietów jest w oryginalnym repozytorium, jednak nie wszystkie pakiety źródłowe posiadają publiczne linki, tak aby można je było umieścić w samym pakiecie.

Rozwiązaniem jest np. tworzenie pakietów w repozytorium https://www.myget.org/, a same binarki trzymać np. 2 miejscach – firmowy intranet oraz linki publiczne.

Ponieważ mnie zawsze brakuje wspomnianych pakietów przedstawiam wam własne źródło, gdzie postaram się uzupełniać przydatne i brakujące pakiety.

Kilka zasad:

1. Wszystkie pakiety binarne trzymane są w moim Dropboxie – katalog /public/choco.
2. Wszystkie pakiety binarne podpisane są SHA256
3. Wszystkie pakiety są weryfikowane przez Virus Total a ich suma SHA256 MUSI zgadzać się z sumą z linka VirusTotal. W opisie pakietu widnieje ich suma kontrolna.
4. Repozytorium jest publiczne – jeżeli chcesz umieścić swój pakiet – odpowiadasz za niego 🙂

Bez zbędnej zwłoki:

Samo źródło: https://www.myget.org/feed/Packages/public-choco

Nuget v2: https://www.myget.org/F/public-choco/api/v2

RSS źródła z pakietami: https://www.myget.org/RSS/public-choco

Jak dodać źródło do swojego Chocolatey’a?

choco source add -n=NAZWA -s"https://www.myget.org/F/public-choco" --priority=10

Jak zainstalować/aktualizować pakiet?

choco install nazwapakietu -y

choco upgrade nazwapakietu -y

Jak usunąć pakiet?

choco uninstall nazwapakietu -y

Jakie pakiety są w repo?

Na dzień dzisiejszy:

WPS-Office-Personal – https://www.myget.org/feed/public-choco/package/nuget/wps-office-personal

Zabbix-Agent3 – https://www.myget.org/feed/public-choco/package/nuget/zabbix-agent3

Pozostałe pakiety przerabiam z sum kontrolnych MD5 na SHA256 co zajmuje mi nieco czasu.

https://bitbucket.org/marcinbojko/hv_default

I decided to make my script public via GitHub. What it does is helping making new Hyper-V installation easier. This little thing helped me in numerous Hyper-V deployments.

https://github.com/marcinbojko/hv_default

Nie jest tajemnicą, iż uważam Microsoft za firmę, w której myśl inżynieryjna jest tłamszona przez część schizofreniczno-marketoidalną, co widać w ich kolejnych posunięciach. Brak jakiejkolwiek możliwości wpływania przez inżynierów na swoje produkty, częste zmiany zasad gry w połowie rozgrywki, paranoidalne trzymane się jedynie rynku USA (nie chcę nawet komentować wykastrowanego XBL w PL). Po kolejnej konferencji, na której widzę te same twarze „celebrytów-evangelistów” wiem, że nic się w tej sytuacji nie zmieni na dobre.

Tym, którzy nie widzieli – polecam, to niezły otwieracz oczu:

Rynek i chęć współpracy z produktami Microsoftu ratują dla mnie REALNI (nie ewangeliczni) MVP – ludzie zatrudnieni na co dzień w przeróżnych firmach, zajmujący się realnymi problemami, rozwiązującymi je i dzielącymi się tym z całym światem.

Swoją przygodę z Hyper-V zaczynałem od próby weryfikacji różnic pomiędzy produktami konkurencji – język Technetu to beznadziejna maszynowa nowomowa, która w żaden sposób nie wyjaśnia jak osiagnąć to co próbujesz. Śmiało moge powiedzieć iż siedziałbym jeszcze w epoce IT łupanego, gdyby nie kontakt z MVP – ludzmi, którzy częściowo bezinteresownie przeprowadzali nas przez meandry korporacyjnych zawiłości.

Obecnie, aby pozostać w obiegu (na bełkot Microsoftu szkoda mi czasu) sledzę:

• Mało przydatne:

System Center: Virtual Machine Manager – http://blogs.technet.com/b/scvmm/

W zasadzie tylko komunikaty o poprawkach i opisy rozwiązań problemów, już dawno przez społeczność rozwiązanych.

Virtualisation Blog – http://blogs.technet.com/b/virtualization/default.aspx

Jak wyżej.Niestety.

• Obowiązkowe (Microsoft, Hyper-V, File Server)

Łukasz Kałużny – http://blog.kaluzny.pro/ – Blog Łukasza był dla mnie początkiem próby zrozumienia działania i przewagi HyperV. Chociaż ostatnio pisze rzadziej, sposób w jaki przekazywał powodował iż na początkowym etapie bywał po prostu niezastąpiony.

Aidan Finn – http://www.aidanfinn.com/ – wyszczekany, niepoprawny politycznie, hejter Linuksów i VMWare. Wrzuca zarówno rozwiązania swoje, jak i w formie agregatora newsów rzeczy związane z Hyper-V, Azure. Nie boi się w mało delikatny sposób zaznaczyć kto w Microsofcie ma problemy z głową przy wprowadzaniu (tak, tak! więcej zamieszania w licencjonowaniu i supporcie) nowości.

Ben Armstrong – http://blogs.msdn.com/b/virtual_pc_guy/ – Manager programu Hyper-V. Gość z niesamowitą wiedzą, dzielący się DZIAŁAJĄCYMI rozwiązaniami w ramach oficjalnego uczestnictwa w programie Microsoftu.

Jose Barreto’s Blog – http://blogs.technet.com/b/josebda/default.aspx – kolejny uczestnik programu Microsoftu (FIle Server Team). Jego posty z kolei skupiają się na rozwiązaniach z zakresu Storage. Nie ma co jednak zapominać iż Storage to SILNY i KLUCZOWY parametr dobrego hypervisora.

Didier Van Hoye ‚Working Hard in IT’ – http://workinghardinit.wordpress.com/ tam gdzie zawiodą oficjalne sposoby Microsoftu, lub osoby powyżej mają związane ręce z powodów oficjalnych, tam wkracza Didier. Jego artykuły mogą uratować Ci życie (lub karierę) w przypadku kolejnego świetnego pomysłu marketingu czy kierownictwa Microsoftu. Dobrze Wam radzę – wrzucać jego notki do Evernota czy Pocketa bo w chwili kryzysu mamy rozwiązanie podane jak na tacy.

Michael Rueefli AKA Dr.MIRU – http://www.miru.ch/ Michael skupia się na najbardziej niedocenionym obecnie pomyśle Microsoftu czyli HyperV Replica. Z tym rozwiązaniem jest świetnie jak działa – jak nie działa, to na 99% Michael JUŻ wie dlaczego i co zrobić.

Kristian Nese – http://kristiannese.blogspot.com/ – Azure i HyperV

• Obowiązkowe – sensowni ludzie w PL

Agregator Ziembora – http://ziembor.pl/plitproblogs/ – Skupia wpisy profesjonalistów w PL piszących dla innych, celem pomocy. Nieopatrznie powiem, iż poniższy blog jest w nim obecny.

Chociaż w żaden sposób nie pretenduję do powyższej czołówki (charakter mojej pracy nie pozwoli mi specjalizować się tylko w kilku wybranych technologiach) chciałbym wierzyć (i wierzę, patrząc na statystyki i maile ze swojego bloga) iż komuś tak sprezentowane rozwiązanie przyda się w krytycznej chwili.

Serdeczne podziękowania dla Michała Panasiewicza (z którym sprzeczam się równie często, co namiętnie) jako inspiracji dla powyższego wpisu.

I jak wyżej – szanowni Microsoftowicze – MVP są naprawdę jedynym powodem, który przepycha mnie przez codzienne obcowanie z waszymi technologiami.

As we all know – disk space isn’t free. If you allocate disk space to your virtual machine, you always want to allocate proper, well-balanced size to shorten future downtimes. But what is proper and balanced you ask?  There is no short answer to this, but if you’re  IT person, you always will try to allocate more than is needed right at the moment.  The decision is : should I use static or dynamic disks?

For me, there is no really need to use static disks anymore as there is no real speed difference. So, the real pro using dynamic disk is their smaller size.

In production environment, using Microsoft’s hypervisor, we can expect our VM to grow over time. During the nature of virtual machines and virtual disks, the real data machine uses are not the same numbers as virtual disk sizes. It is happening due to hypervisor behaviour – deleting all data from OS in virtual machine is no more than throwing away and index card from your book. The written data are still there, so there is no easy, automated way to compact a virtual disk.

Hypervisor however, tries to allocate in a first place, blocks marked as used. So the real expanding is happening when you’re constantly changing your data, without deleting them first. The great example is with databases, log and temporary trash disks and just plain and simple oversizing. I’ve had a case when relativly small machine (20 GB CentOS with a 600 GB VD) just grew over few days filling whole 600 GB of data because of logs set to DEBUG.

So what will be the cons and of virtual disk growing overtime?

• obviously, more space allocated at expensive storage for VMs
• more obviously, when you’re using any kind of backup software, you’re forced to write and store in multiple copies the data you really doesn’t need
• CBT (Change Block Tracking) Table is bigger to process, with every move
• more network traffic with every backup job you have
• live ‚shared nothing’ migration times grows just out of proportions. If you have a small machine with 20GB data on 600 GB sized disk, you will have to transfer this whole fatso over you network to other machine. Even with compression set at live migration, it is just really unwanted.

So what can we do? We can just zero the data you’re not using and Hyper-v cmdlets  will take the rest.

You have to plan downtime for the machine, but according to my tests, zeroing machines with 600 GB took 15 to 30 minutes. With smaller sizes it is just matter of single minutes.

Before you go:
– plan your downtime, compacting should not to be interrupted
– take extra caution. Zeroing important data or uneeded data it’s just a matter of mistake.
– delete all snapshots/checkpoints
– make sure you converted VHD to VHDX (optional)
– make sure your disk is set as dynamic disk
– make sure you have enough room for compacting or resizing. Remember – if you have 600 GB virtual disk, during this process it may grow to this size.
– remember that compacting deletes CBT table for backup software – next backup will be a Full Backup.

The most usable zeroing ways I found was:

Offline methods

Cons
– longer downtime
Pros
– more accurate (no more background write)
– faster (no more background write)
– smaller risk of processes failure due to ‚out of space’ event

• zerofree for Linux ext2/ext3/ext4 disks
• ntfswipe for Windows based disks
• dd for both Linux and Windows based disks or exotic fs (btrfs/xfs)

Online methods
Cons
– less accurate (background write  is still happening)
– machines became slower or unresponsible
– slower process
– risk of applications failing due to ‚out of space’ events
Pros
– smaller downtime

– SDelete or CCleaner for Windows based disks
– dd for Linux based disks

Phase I – Zeroing Offline

Offline zeroing (done with System Rescue CD 4.x)

• Delete all uneeded data (logs, temps, bigfiles, dowloads, caches)
• Umount all ext2/3/4/ntfs volumes
• for NTFS volume: ntfswipe -av /dev/volume_name
• for ext2/3/4 volume: zerofree -v /dev/volume-name
• for LVM: vgchange -a y;zerofree -v /dev/mapper/volume_name

Zeroing swap space:

# swapoff -a

# free
total used free shared buffers cached
Mem: 8056340 2643132 5413208 155072 606916 914796
-/+ buffers/cache: 1121420 6934920
Swap: 0 0 0

# blkid |grep swap
/dev/sdb2: UUID="adad0488-3b67-4444-b792-6a1a775b8821" TYPE="swap"

# dd if=/dev/zero|pv -treb|dd of=/dev/sdb2 bs=8192
dd: error writing ‘/dev/sdb2’: No space left on device
1,91GB 0:01:04 [30,3MB/s]
249981+4 records in
249980+4 records out
2047868928 bytes (2,0 GB) copied, 67,931 s, 30,1 MB/s

#mkswap /dev/sdb2 -U "adad0488-3b67-4444-b792-6a1a775b8821"
Setting up swapspace version 1, size = 1999868 KiB
no label, UUID=adad0488-3b67-4444-b792-6a1a775b8821

# swapon -a

# free
 total used free shared buffers cached
Mem: 8056340 3309648 4746692 159844 1112232 919708
-/+ buffers/cache: 1277708 6778632
Swap: 1999868 0 1999868

Phase I – Online zeroing

1. Delete all uneeded data (logs, temps, bigfiles, dowloads, caches)

for Windows machine
sdelete -z letter:

Linux machine
#dd if=/dev/zero|pv -treb|dd of=/file.zero bs=4096;sync;sync;rm -rfv /file.zero;sync

Phase II – Compacting

1. Shutdown the machine

For System Center VMM 2012 R1/R2

👁 Workspace 1_107

For Hyper-V powershell

Optimize-VHD -Path path_to_vhdx_file.vhdx -Mode Full

👁 Workspace 1_108

——-
System Rescue CD – http://www.sysresccd.org/Download
SDelete – http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx
CCleaner Portable – https://www.piriform.com/ccleaner/builds
zerofree – http://manned.org/zerofree/00be91ab

Dla nas wszystkich, uzależnionych od XBMC wygodne zdalne nim sterowanie zawsze było kluczową korzyścią. Wygodny i stabilny klient Official XBMC Remote oferował tryb biblioteki, tryb pilota, sterowanie gestami, podstawowe notyfikacje i tym podobne rzeczy. Niestety, jednak wliczając w w to buildy developwerskie, jego ostatnie wersje pochodzą z końcówki 2012 (lub początku 2013 – w zależności od używanej wersjii), przez co nie do końca potrafią wykorzystać możliwości zarówno obecnego hw, jak i nowych funkcjonalności, które pojawiły się w XBMC 13.x Gotham.

Godnym (i równie darmowym) następcą okazał się być Yatse – dostępny w Sklepie Play:  https://play.google.com/store/apps/details?id=org.leetzone.android.yatsewidgetfree

Nowe i poprawione funkcje:

– prześliczne tematy i wygląd bilbioteki

– obsługa lockscreen (sterowanie, kontrola, tapeta)

– kontekstowa funkcja ‚send to xbmc’  dla materiałów multimedialnych w Twoim urządzeniu – obsługa Google Chromecast

– chmura dla Twoich hostów XBMC

Strona główna

👁 2014-06-21 19.32.38

Tryb biblioteki

👁 2014-06-21 19.32.42

Lockscreen

👁 2014-06-21 19.32.22

I auto-tapetka na ekranie głównym (znika po zastopowaniu mediów, lub wybraniu innego) 🙂

👁 2014-06-21 19.32.31

Ostatnio, dzięki koledze z pracy, odkryłem całkiem ciekawy dysk w „chmurze” – PogoPlug.com, który za skromną, miesięczną 4 dolarową opłatą pozwala nam korzystać ze swoich zasobów w formie ‚unlimited’. Przy okazji – dziękuję Marcinie 😉

Dostarczany klient, dla systemów Windows i MacOS raczej funkcjonalnością nie powala, jednak ma sporo niedogodności:

– domyślnie wpycha do chmury foldery ‚Moje dokumenty’, ‚Moja Muzyka’, ‚Moje filmy’ itp, itd, czyli cały ten Windowsowy śmietnik (kto nie wierzy niech zajrzy do ‚Moich dokumentów’, najlepiej z włączonym podglądem plików systemowych i ukrytych. Nie można tej opcji wyłączyć (trzeba każdorazowo zatrzymywać ich kopiowanie).

– chmura działa jak czarna dziura – plik usunięty na dysku źródłowych, egzystuje w nieskończoność na dysku chmurowym. Rozwiązanie fajne dla zagapionych, ewangelistów Windowsa i przepłacanych blogerów Apple. Dla tych normalniejszych, synchronizacja jest rozwiązaniem właściwym.

– kontrola nad plikami nie powala – lepiej powiedzieć, nie ma jej wcale ;(

– nie da się skorzystać z robocopy, fastcopy czy jakiegokolwiek ręcznego copy ;(

Na szczęście, w systemie Linux, potraktowanemu po macoszemu przez twóców chmury, rozwiązaniem jest pogoplugfs, który montuje nam dysk chmurowy we wskazanym przez nas folderze. Oczywiście automatyzujemy proces (fuse lub udev), co więcej wykorzystując graficzne narzędzia jak grsync wyciągamy z chmury to co najlepsze 😉

Cały proces mamy precyzyjnie opisany tutaj: http://tuxtweaks.com/2013/06/mount-your-pogoplug-on-linux/, ja skupię się na samym rsync/grsync i małej potyczce z mechanizmem chmurowym.

PogoPlug oferuje bardzo sympatyczny (chociaż prościutki) interfejs do obsługi naszych plików multimedialnych. Pliki muzyczne czy wideo możemy sobie streamować na urządzenia mobilne (lubo dtwarzać poprzez interfejs webowy) tworząc naszego prywatnego Deezera.

A wygląda to tak:

👁 Image

Co ciekawe, podczas transferu za pomocą grsynca, pliki przesyłały się poprawnie (właściwa suma md5), jednak z nieznanych mi powodów nie pojawiały się w interfejsie, w sekcji multimedialnej. Dotyczyło to zarówno plików audio jak i wideo. Pliki istniały we właściwych folderach, jednak zawsze typem pliku było ‚file’ zamiast ‚music’ czy ‚video’. Po krótkim śledztwie winowajcą okazał się standardowy sposób w jaki rsync/grsync przesyła dane. A robi to tak:

Załóżmy iż wysyłamy plik o nazwie: muzyka.mp3. Rsync wysyła go jako ‚muzyka.m3.RANDOMCHARS‚, po poprawnie zakończonym procesie transferu zmienia mu nazwę na ‚muzyka.mp3’.  Zachowanie to zmieniamy dodając parametr –inplace i już możemy cieszyć się zarówno poprawnie wykonaną kopią zapasową, jak też i strumieniowaniem naszych utworów muzycznych 😉

Jak wiele razy pisałem – nie przepadałem za dystrybucjami Linuxa tworzonymi specjalnie pod desktopy. Gdzieś mniej więcej w środku wojny o scheduler (2007/2008) dystrybucje dzieliły się na szybkie oraz użyteczne 😉 W gałęzi numer jeden królowały Debiany, Arch oraz Gentoo, w gałęzi drugiej o palmę pierwszeństwa walczyły OpenSuSe, Ubuntu i gdzieś po cichu Fedora.

Pamiętam wtedy mój zachwyt dystrybucją Linux Mint – Glora (v7) wydana w edycjach Gnome/KDE a następnie Fluxbox/Xfce gdzieś koło połowy 2009 roku. Okazało się iż można było wykorzystać gotowe paczki z innej dystrybucji (Ubuntu/Debian), zrzucając żmudną robotę dopasowywania pakietów i przebudowywania zależności na Canonical, samemu zajmując się ulepszaniem użyteczności oraz pracami koncepcyjnymi.

Stopniowo, ścieżka którą obrał zespół Minta – słuchanie głosów swoich użytkownika doprowadziła do postania edycji Helena (v8), Isadora (v9), Julia (v10) kończąc edycją Katya (v11) w 2011 roku. W tym czasie Ubuntu chaotycznie zmieniało środowisko (Gnome Shell/Unity), tematy, domyślne oprogramowanie (wyrzucając chociażby Gimpa uznanego przez nich za ‚zbyt skomplikowany’, czy zastępując komunikator Pidgin mniej znanym Empathy) co dla większości z nas było bardzo męczące.

👁 2014-01-Blog-Cicha-rewolucja-1

Tak głębokie ingerencje w drzewa pakietów i zależności oraz stopniowa walka z przyzwyczajeniami użytkowników spowodowały iż edycje 10.10/11.04 przez wielu uznane zostały za bardzo niestabilne, ociężałe i kompletnie rozbieżne z oczekiwaniami użytkowników. Fora pękały od porad: jak usunąć daną funkcjonalność, jak dodać coś co zostało w Ubuntu pominięte, oraz co zrobić w przypadku gdy po kolejnej aktualizacji system nie nadawał się do użytku: bądź to odmawiał dalszej współpracy lub też usuwał wszystkie tweaki, które użytkownicy nazbierali do tej pory.

Wprowadzenie interfejsu Unity było dla wielu z nich ostatnią kroplą przepełniającą czarę goryczy – co kilka lat później otrzymał Microsoft wprowadzając interfejs Modern UI/Metro w systemie Windows 8. Niestety, alternatywy dla Unity były równie nieciekawe: zarówno KDE jak i Gnome Shell/Gnome 3 cierpiały na klasyczne choroby wieku open-source: nowe funkcjonalności kosztem stabilności.

👁 2014-01-Blog-Cicha-rewolucja-5

Team Linux Mint, po raz kolejny podjął decyzję słuchając swoich użytkowników, decydując się na wprowadzenie autorskiego UI – Cinnamon (fork Gnome Shell) oraz forka Gnome 2 – MATE. Tym sposobem, dla słabszych maszyn lub dla użytkowników przyzwyczajonych do klasyki Gnome, pozostał właśnie MATE. Dla posiadaczy maszyn ze wsparciem grafiki 3D oraz dla zwolenników nowych funkcjonalności w starej otoczce przeznaczony był interfejs Cinnamon.

Nie obyło się jednak bez problemów – Cinnamon wraz z managerem plików Nemo (fork Nautilusa wprowadzony w edycji 1.6) wprowadzony oficjalnie w roku 2012 w edycji Maya, był również mało stabilny, przynajmniej w początkowych fazach tworzenia, wciąż silnie zależąc od Gnome. Pierwsze naprawdę stabilne i użyteczne funkcje pojawiły się w edycji Linux Mint 14 (Nadia), stopniowo kontynuowane w bardzo niestabilnej edycji Mint 15 (Olivia). W 2013 roku, wydając edycję Mint 16 (Petra) twórcy wprowadzając wersję Cinnamon 2.0 obwieścili, iż do działania nie wymaga on już w żadnym stopniu środowiska Gnome (w przeciwieństwie do Unity czy Gnome Shell). W tej edycji Cinnamon stał się pełnoprawnym środowiskiem desktopowym, pozwalając na uniezależnienie się od coraz mniej stabilnego pierwowzoru.

👁 2014-01-Blog-Cicha-rewolucja-2

To własnie Linux Mint 16 (Petra) określany przeze mnie „cichą rewolucją” stał się tym, czym od wielu lat próbowało zostać Ubuntu – dystrybucją, której łatwość instalacji, kompletność oraz możliwość uruchomienia większości opcji „out-of-the-box” spowodowały wzmożone zainteresowanie środowisk do tej pory Linuksa unikających. Widać to dosyć wyraźnie na wykresach organizacji DistroWatch – od 6 miesięcy Linux Mint podwoił dystans jaki dzielił od niego Ubuntu.

Od paru lat jako użytkownik desktopowego Linuksa (OpenSuSe/Mint/Ubuntu) swoje pierwsze kroki po instalacjach wszystkich tych systemów zaczynałem od wielu tweaków – od wyłączenia nieszczęsnych fortune cookies w terminalu zaczynając, poprzez aktualizację managerów pakietów, dodawanie nowych repozytoriów załatwiających to, co edycje stabilne załatwić nie mogły, na nowym kernelu kończąc. I wyobraźcie sobie moje zdziwienie, gdy w edycji 16, przenosząc większość swojego katalogu /home, dorzucając dodatkowe repozytoria Noobslabs (ikonki), dorzucając kilka pakietów z poza repo (Apache Directory Studio, Sublime Text, PAC Manager, Double Commander) po raz pierwszy od kilku lat mogę powiedzieć: wszystko działa.

👁 2014-01-Blog-Cicha-rewolucja-3

Zaczynając od faktu, iż mój Linux zmieścił się na dysku SSD wykorzystywanym przez Windows 7/8 mojego ultrabooka jako cache (16 GB). Dzięki temu w niecałe 10 sekund po uruchomieniu komputera jestem w stanie przystąpić do pracy.

Jestem w stanie bez żadnej filozofii podłączyć urządzenia oparte na systemie Android, nawet te uparcie wspierające tylko MTP. Lepiej niż w systemie Windows, mogę dowolnym filemanagerem buszować po ich zasobach, podczas gdy Eksplorator Windows dawał mi jedynie możliwość copy/paste, co plik przerywając komunikatem ‚konwertować czy nie?’.

Bez żadnych problemów korzystam z zasobów domenowych (w tym firmowego DFS’a), dobrodziejstw rozwiązań Fortigate czy Cisco (tego ostatniego oczywiście przez open-source, bo sami są za leniwi aby coś stworzyć)
WINE bez problemów uruchamia moje edycje Microsoft Office (skończyłem na kupieniu MS Office 2010), od dawna jednak polegam – również w edycji Windowsowej na doskonałym Kingsoft Office (swoją drogą to paranoja, iż cały pakiet  a la Office można zmieścić w 120 MB, podczas gdy jego poprzednik zaczyna od paru giga śmiecia).

Synapse wraz z pluginami jak Zeitgeist działa lepiej, szybciej i wydajniej niż Windows Search/Indexing.

Doskonały PAC Manager – do zarządzania sesjami remote (vnc/rdp/ssh/telnet/serial/itp/itd), Double Commander powielający 1:1, łącznie z pluginami, wszystkie funkcje mojego Total Commandera, Thunderbird+Lightning, Chrome – wymieniać można tak w nieskończoność.

👁 2014-01-Blog-Cicha-rewolucja-4

Korzystąjąc z dobrodziejstw rozwiązań chmurowych, większość moich danych jest swobodnie wymienialna pomiędzy systemami operacyjnymi. Kończąc pracę na Linuksie, dane zapisywane są do odpowiednio zamapowanych katalogów Dropboxa (lub korzystając z rozwiązań natywnych jak Chrome, Last Pass,Evernote czy Xmarks). Chwilę później mogę podjąć ją na systemie Windows, kontynuując tam gdzie skończyłem.

Ba, powoli ostatni bastion oporu jakim są gry został skutecznie nadgryziony (bo o obaleniu jeszcze mówić nie można) poprzez wprowadzenie najpierw PlayOnLinux a ostatnio klienta Steam, gdzie liczba gier zwiększa się z miesiąca na miesiąc.

NetworkManager z pakietami Wireshark, Zenmap nping czy dhcp-probe pozwalają mi na szybsze dopasowanie się do profili sieciowych i diagnostykę pojawiających się firmowych problemów. Z Linuxa daje się zarządzać systemami VMWare, Microsoft (Hyper-V , Windows Server, System Center) czy Citrix Xen. Dzięki dobrodziejstwu maszyn wirtualnych znika ostatnia bariera tam, gdzie do tej pory wydawało się iż Linux nie ma wstępu.

Faktycznie przez ostatnie parę miesięcy chyba tylko dwukrotnie musiałem skorzystać z faktu posiadania dwóch systemów: w obu przypadkach był to software przeznaczony do rootowania telefonów, co ciekawsze drugi z nich stanowił zlepek cygwina i unixowych portów jak wget/curl czy dd 🙂

Kończąc na dzisiaj: z wprowadzeniem wieloplatformowych aplikacji i środowisk jak Chrome, Dropbox, Evernote czy wspomniany Kingsoft Office, sam system operacyjny zaczyna spełniać rolę, którą do tej pory pełnił kernel.  Zadaniem OS pozostaje sprawne zarządzanie elementami hardware, przydzielanie i zwalnianie zasobów oraz podstawowe możliwości interfejsu użytkownika.

Zawsze stałem na stanowisku: Linux to nie OS – to zestaw narzędzi do sporządzenia Twojego idealnego, dopasowanego w 100% systemu operacyjnego. Dlatego, moim skromnym zdaniem, systemy skrojone tak aby działały na określonym hardware, w określony, wybrany TYLKO przez twórców sposób, gromadzą ludzi, którzy spędzają więcej czasu na walkę z tymże OS aby dopasować go do ludzkiego sposobu myślenia, niż my, fandom Linuksowy, który posiadając gotowe narzędzia, dopasowuje OS do swoich potrzeb.

I tak, mam także na myśli Canonical, którego decyzji już chyba nikt nie rozumie (wie o tym każdy, kto usiłował pozbyć się Unity czy też sponsorowanych przez Amazon wyników jego wyszukiwania).

Z Linuksem Mint 16, ta praca u podstaw jest o wiele łatwiejsza.

Aby jednak nie było tak dobrze, powiem wam Co w roku 2014 wciąż mnie w Linuksach uwiera i denerwuje. Ale, to już inna bajka.

Dziś parę słów o urządzeniach, na które większość z nas nie zwraca większej uwagi: mianowicie urządzenia drukujące, drukująco-skanujące (MFP/MFD – Multi Function Printer/Multi Function Device) oraz popularne kserokopiarki. Przyzwyczajeni do tego, iż z wyjątkiem uciążliwych zacięć papieru oraz uzupełniania materiałów eksploatacyjnych niewiele się z nimi dzieje, przespaliśmy epokę, w której urządzenia te stały się tak samo skomplikowane jak komputery z których drukujemy.

Z uwagi na specyfikę pewnych firm (zwłaszcza w PL), opartych wciąż na przetwarzaniu papierowych wydruków, urządzenie takie często stanowi centrum nerwowe spółki. Ze stopniem skomplikowania idzie niestety podatność na ataki, exploity oraz nadużycia, które podzielić możemy na 3 podstawowe grupy.

Pierwsza z wymienionych grup to właśnie włamania i exploity wykorzystujące fakt, iż urządzenia drukujące korzystają ze zmodyfikowanych popularnych pakietów (zarówno o kodzie otwartym jak i zamkniętym) jak: Apache, Lighttpd, Java, PHP czy też ogólnie dostępne silniki bazodanowe. Wszystkie te wymienione pakiety możemy chociażby spotkać podczas korzystania z paneli lub konsol sterujących dla wskazanych urządzeń. Opieranie się na gotowym kodzie niesie za sobą niebezpieczeństwo wystąpienia błędów, które z uwagi na społecznościowy charakter oprogramowania open-source, są szybko wychwytywane i ujawniane publicznie. Cykl wytwarzania oprogramowania open-source pozwala na szybszą reakcję w celu korektę błędu, podczas gdy w przypadku oprogramowania funkcjonalnego o zamkniętym kodzie (jak np. firmware urządzeń drukujących), do czasu załatania błędów przez producenta, jesteśmy narażeni na ataki i exploity.

Na jakiego dokładnie typu zagrożenia jesteśmy narażeni?

Zdobycie hasła administracyjnego w urządzeniu pozwala na zmianę wszystkich parametrów procesu drukowania: złośliwe strony z bannerami, zmiana parametrów wydruku (kolor/odcienie szarości), zmiana rozdzielczości, zmiana ACL dla określonych IP, zmiana adresów e-mail lub ustawień serwera SMTP skojarzonego z kontem urządzenia drukującego. W kilku określonych przypadkach zdobycie dostępu do urządzenia może również spowodować zdobyciem dostępu do panelu serwisowego, gdzie zmiany dokonane przez atakującego mogą być o wiele bardziej bolesne. Istnieją udokumentowane przypadki gdy za pomocą zmiany parametrów serwisowych napastnik był w stanie doprowadzić do uszkodzenia urządzenia (sterowanie temperaturą nagrzewania)

W przypadku wdrożonych systemów autoryzacji i rozliczeń (Authorisation and Accounting), atakujący może na przykład wpłynąć na zmianę raportów o ilości wydrukowanych stron i dokumentów w rozbiciu na poszczególnych użytkowników. Łatwo można sobie reakcję kontrolującego, jeżeli na koncie któregoś z użytkowników pojawią się nazwy zadań drukowania o swojsko brzmiących nazwach bestselerów czytelniczych.

Dostęp do panelu serwisowego niesie za sobą również inne zagrożenia – część znanych mi urządzeń MFP/MFD posiada opcję ‚mirror’, czyli wysyłania WSZYSTKICH zadań, czy to wydruku, czy to skanów, na wskazany adres serwera FTP/SMB. Napastnik, wykorzystując hasło domyślne urządzenia, lub przechwytując hasło administracyjne, ustawiając prostą i dobrze udokumentowaną funkcję zapewnia sobie dostęp do wszystkich dokumentów przepływających prze wskazane urządzenie. Dotyczy to zarówno wydruków, skanów oraz popularnych kopii.

Popularny, prosty w przeprowadzeniu i stosunkowo trudny w diagnozie atak typu DoS pozwala na zatrzymanie pracy urządzenia, podczas gdy jedynym rozwiązaniem wyjścia z impasu okazuje się restart urządzenia.

Drugi typ zagrożeń jaki pojawia się przy urządzeniach drukujących ma na celu, oprócz unieruchomienia urządzenia, spowodowanie jak największych strat dla właściciela urządzenia. Nie jest tajemnicą, iż koszty materiałów eksploatacyjnych potrafią być bardzo wysokie, zwłaszcza w przypadku kolorowych urządzeń wielkoformatowych posiadających dodatkowe banki na papier. Bardzo popularną formą „outsource” dla urządzeń drukujących jest tzw. CPC (Cost Per Copy), gdzie w opłacie za każdą wydrukowaną czy zeskanowaną stronę użytkujący płaci firmie wynajmującej zryczałtowaną opłatę. Opłata zawiera w sobie przykładowo: koszt materiałów eksploatacyjnych w tym materiałów mechanicznych, jak rolki czy pasy transferowe, koszt elementów serwisowych (parts & labour), SLA itp. Umowy takie często zawierają klauzule o wyłączeniu odpowiedzialności właściciela urządzenia przy przekroczeniu średniego pokrycia strony (zazwyczaj od 2 do 8%).
W przypadku braku ograniczenia dostępu łatwo można doprowadzić do efektu gdzie dowolna osoba uruchomi zapętlone wydruki np. zdjęć w wysokiej rozdzielczości czy też wydruków próbnych (z reguły posiadających sporą gamę kolorów), błyskawicznie wyczerpując zarówno materiały eksploatacyjne (w tym wspomniane pasy transmisijne) jak i papier. W wysoko zautomatyzowanych środowiskach, gdzie oba te czynniki podlegają automatycznemu uzupełnianiu, raporty ze zużycia drukowane są np. w systemie miesięcznym, brak kontroli nad tym czynnikiem może narazić nas na spore straty.

Trzeci typ zagrożeń dotyczy dostępu do przetwarzanych treści.
– dostęp do fizycznego urządzenia, gdzie dowolna osoba może zapoznać się z treścią przetwarzanego dokumentu
Na nic najwymyślniejsze systemy zabezpieczeń w sytuacji gdy wiele osób lub działów używa tej samej puli urządzeń drukujących. Od momentu zlecenia wydruku, do momentu fizycznego odbioru zadrukowanych kartek potencjalnie dowolna (nawet postronna) osoba może dostać się do naszych danych. Bardzo częstym przypadkiem jest ustawianie urządzeń drukujących w miejscach, przez które przewija się spora ilość osób: sekretariat, recepcja, korytarz, sala konferencyjna.
– dostęp do nie zabezpieczonej sieci, w której atakujący może przechwycić dane wysłane do urządzenia drukującego.
W znakomitej większości urządzeń drukujących wystarczy przechwycić plik RAW skierowany do wydruku aby za pomocą oprogramowania rasteryzującego lub identycznego urządzenia zapoznać się z treścią wydruku.
– dostęp do kont użytkownika (boxes) zakładanych na urządzeniu.
Urządzenia MFP/MFD pozwalają na nieskomplikowane zarządzanie użytkownikami poprzez zakładanie im tzw. kont użytkownika (boxes). Brak autoryzacji powoduje iż dowolny inny użytkownik jest w stanie przejrzeć zawartość wskazanego konta, historię wydrukowanych plików, w znakomitej większości również cały bufor wydruku (przechowywany zazwyczaj na dedykowanym HDD)
– dostęp do haseł czy numerów PIN lub kart identyfikacyjnych innych użytkowników.
W przypadku używania kont użytkowników zabezpieczonych jedno lub dwucyfrowym pinem, ogólnie znanym numerem identyfikacyjnym kojarzonym z określoną osobą (PESEL), bardzo łatwo jest podszyć się pod wskazaną osobę, uruchamiając następnie bardziej wymyślne ataki.
– dostęp do skanów wysyłanych na ogólnodostępne foldery wymiany.
Jeden z popularnych błędów – ogólnodostępny folder wymiany (SMB/WIndows Share/FTP)na który wędrują wszystkie skany w myśl zasady ‚ja tak szybciutko, zaraz usunę, nikt się nie zorientuje’. Nasz podsłuchujący, posiadający prawo do odczytu dla wskazanego folderu ma wiele sposobów na skopiowanie zawartości – cyklicznie wykonywany skrypt, element wykorzystujący flagę ‚on folder change’

Równie popularny, oraz bardzo prosty sposób na zablokowanie urządzenia to … próba wykonania kopii banknotu (euro lub dolara). Tajemnicą poliszynela jest, iż urządzenia takie mają wbudowane zabezpieczenia przed zbyt dokładnym kopiowaniem zabronionych dokumentów (do których należą banknoty). W ten sposób głupi pomysł zostawi nam urządzenie zablokowane, często niezdatne do dalszej pracy bez dodatkowych zabiegów ze strony producenta.

Gdy już wiemy na jakie zagrożenia jesteśmy narażeniu postarajmy się zaprojektować bezpieczniejsze środowisko pracy naszych urządzeń drukujących.

Kontrola dostępu do fizycznego urządzenia

– secure room/copy room (Bezpieczne pomieszczenie)

Jeżeli mamy taką możliwość, urządzenia drukujące powinny być odizolowane od osób postronnych (goście, petenci) w postaci wydzielonego pomieszczenia z kontrolą dostępu. Wspomniana wyżej sytuacja, gdzie z racji braków lokalowych urządzenia stoją na korytarzach, są jawnym naruszeniem zasad bezpieczeństwa.

– jedno urządzenie per pomieszczenie zamiast kilku mniejszych.
Popularny mit zwłaszcza w instytucjach jak urzędy państwowe – każdy z urzędników po prostu musi mieć swoją drukarkę. Tymczasem tak naprawdę wystarczy jedno urządzenie sieciowe umieszczone centralnie w pomieszczeniu, tak by nie istniała konieczność porzucenia na pastwę petenta swojego stanowiska pracy. Co w przypadku gdy każdy z urzędników chce mieć swój wzór papieru lub dokumentu? Urządzenie wyposaża się w dodatkowe kasety lub banki papieru, co wciąż jest rozwiązaniem bardziej oszczędnym niż oddzielne urządzenie drukujące.

– blokada fizycznych przycisków i panelu sterującego
Z rozwojem urządzeń drukujących coraz więcej ustawień daje się wprowadzać za pomocą fizycznych przycisków lub paneli. CO więcej, spora część opcji serwisowych z domyślnymi hasłami jest dostępna w ten sposób. Oprócz oczywistych możliwości do zamiany ustawień urządzenia istnieje realne niebezpieczeństwo jego uszkodzenia poprzez ingerencję w parametry serwisowe (jakim są np. temperatury urządzeń utrwalających)

– stworzenie kont użytkownika z uwierzytelnieniem za pomocą kart aktywnych, PIN lub danych z serwera LDAP.
Bardzo przydatna opcja w przypadku gdy chcemy zabezpieczyć się przed nadużyciami lub wprowadzić rozliczenie ilości i jakości wydrukowanych materiałów w podziale na użytkownika czy dział. Dodatkowo, scentralizowana baza danych zabezpieczy nas przed dodatkową pracą utrzymywania i synchronizacji kolejnych baz.
– automatyczne wylogowywanie z nieużywanych profili i kont użytkownika
W przeciwnym wypadku kolejny użytkownik jest niemalże kuszony opcją skorzystania z ustawień poprzednika.

– włączenie opcji „follow me printing”
Bardzo przydatna opcja w przypadku gdy materiały wydrukowane powinny być dostępne TYLKO dla wskazanej osoby. W przypadku skorzystania z tej opcji możemy zrealizować zadanie drukowania bez żadnych dodatkowych ustawień, wydruk zostanie rozpoczęty dopiero po fizycznym uwierzytelnieniu się na wskazanym urządzeniu z puli. Pozwala nam to na zachowanie poufności drukowanych materiałów bez ekspozycji tychże w pojemniku z zakończonymi wydrukami.

Kontrola dostępu do interfejsu sieciowego

– wydzielenie oddzielnego VLAN dla urządzeń drukujących i przyznawanie dostępu ACL na poziomie komputerów lub użytkowników
Jest to chyba podstawowa opcja jaką należy zastosować w celu ochrony drukowanych danych. W połączeniu z serwerami (lub serwerem) wydruku pozwoli nam na zrealizowanie zasad bezpieczeństwa w prostszy sposób:
– dostęp do kolejek drukowania mają tylko uwierzytelnieni klienci
– drukarkami zarządzamy np. za pomocą Active DIrectory – dostęp do nowego urządzenia i jego instalacja wymaga w zasadzie tylko przeładowania profilu.
– serwer wydruku może swobodniej, bez indywidualnych ACL sięgać do interfejsów sieciowych urządzeń drukujących
– dla klientów Windows i Active Directory można zbudować bezpieczniejsze kanały kontaktu z serwerem wydruku (IPSec) co uniemożliwi podsłuch i możliwość przechwycenia i analizy wydruków.

Kontrola i analiza wydruków.
– dodatkowe oprogramowanie
W zależności od stopnia skomplikowania możemy powierzyć zliczanie stron serwerowi wydruku, lub zdecydować się na dodatkowe oprogramowanie. Warto wspomnieć iż większość urządzeń przechowuje informacje o wolumenie wydruku w podziale na użytkowników, jednak przy ich większej ilości niezbędne jest ręczne podsumowanie.
Na korzyść dodatkowego oprogramowania można zaliczyć fakt, iż w odróżnieniu od serwera wydruku, rozliczaniu w podziale na użytkowników podlegają również kopie wykonywane lokalnie na urządzeniu (off the glass), skany i wydruki niestandardowe (bannery, wydruki 2-kolorowe itp.)
Przykładem takiego oprogramowania może być popularny serwer wydruku PaperCut – dostępny również w wersji darmowej dla 15-użytkowników.
Źródła
(1) https://viaforensics.com/security/exploiting-printers-via-jetdirect-vulns.html
(2) http://www.examiner.com/article/vulnerability-hp-s-jetdirect-software-may-lead-to-exploitable-printers
(3) http://www.rapid7.com/db/vulnerabilities/snmp-hp-0001
(4) http://www.papercut.com/

Nie wkurza was iż w przypadku pustego katalogu z nazwą serialu (ot obejrzałeś wszystkie epizody, czekasz na nowy sezon) XBMC uparcie wyświetla go na liście dostępnych do obejrzenia?

Oczywiście, przy liście dostępnych epizodów wyświetlając puste miejsce?

Odpowiedzią jest plik advancedsettings.xml dostępny w katalogu /xbmc/userdata/ (dla Linuxa jest to ~/.xbmc/userdata, dla Windows zazwyczaj: %appdata%\XBMC\userdata\)

Jeżeli go nie ma, nalezy go stworzyć wklejając zawartość:

<advancedsettings>
<videolibrary>
<cleanonupdate>true</cleanonupdate>
</videolibrary>
</advancedsettings>

dopisać do niego następującą linię:

 
<videolibrary>
<cleanonupdate>true</cleanonupdate>
</videolibrary>
I działa ;)

Prezentacja tradycyjnie dostepna w formie slajdów:

👁 2012-04-25 21.09.44

Dla tych z Was, którzy podobnie jak ja używają XBMC na swoim PC pewnym problemem mogło być sterowanie nim za pomocą pilota. A to wiadomo: trzeba takowy kupić, zainstalować, wrzucić EventGhosta – zamapować akcje, przetestować itp. itd. U mnie stopniowo pozmierały wszystkie akumulatorki AAA – stąd czasem perfidne próby podkradania akumulatorków z i do naszych pilotów.

Z pomocą przychodzi fantastyczna aplikacja dla Androida – XBMC Remote:

👁 Main

Aplikacja wykorzystując LAN (Wifi) i konto do zarządzania zakładane od strony XBMC pozwala nam na:

– zamianę w wirtualnego, dotykowego pilota

– odtwarzanie materiałów via biblioteka – poprzez ścisły podział na zawartośc: serial, sezon, odcinek itp.

– sterowanie samym XBMC (poweroff – nie muszę dodawać jaka to pożyteczna funkcja z poziomu wygodnego łóżeczka?)

Ekran główny:

👁 screen1

Sam pilot:

👁 screen2

Zarządzanie przez bibliotekę mediów (seriale)

👁 screen3

Pojedynczy serial👁 screen4

Epizody w sezonie👁 screen5

Opis opizodów👁 screen6

👁 screen7

👁 screen8

Jak zapewne wiadomo tym, którzy przebrnęli przez poprzednie wpisy o DRBL, system ten dostarcza ciekawy mechanizm umożliwiający dostarczanie kilku pożytecznych narzędzi za pomoca  PXE bezpośrednio do komputera na którym je potrzebujemy. Iż jest to czasem błogosławieństwo chyba nie muszę opowiadać: brak dyskietki, dysku USB, CDROMU, uszkodzenie tychże i tak dalej i tak dalej.

Przykład? Konieczność wykonania akcji ratunkowej/maintenance na badanym systemie – ot klasyczny uszkodzony Windows/Linux do spacyfikowania. Zazwyczaj wykonujemy opcję startu z CD/DVD, czasem klucza USB (bez angażowania dysku twardego), a tu pokażę jak możemy to zrobić łatwiej i przyjemniej: via network. Dzisiaj zajmiemy się dostarczeniem jednego z ciekawszych systemów ratunkowych: System Rescue CD, dostępnego tu: http://www.sysresccd.org

Kilka aksjomatów:

– pokaz przeprowadzam na openSUSE 11.3 z zainstalowanym systemem i prekonfigurowanym DRBL’em w wersji 1.10.31_1

– interfejs dla podsieci DRBL to 172.16.0.1, podsieć 172.16.0.0/24

– obrazy systemów dostarczamy za pomocą http – można to zrealizować poprzez tftp, nfs, nbd – http pozostaje jednak najbardziej uniwersalny dla dodatkowych systemów podpinanych do DRBL’a, jak również stosunkowo najłatwiejszy w konfiguracji.

– zawartość serwera HTTP domyślnie znajduje się w /srv/www/htdocs

– zawartość DRBL/Tftpd domyślnie znajduje się w /tftpboot/nbi_img

– plik konfiguracyjny drbla znajduje się w /tftpboot/nbi_img/pxelinux.cfg/default

– wszystkie operacje wykonujemy jako root/sudo su

Zaczynamy od pobrania ostatniej wersji System Rescue CD – na potrzeby manuala jest to 2.3.1, ale oczywiście powinno działać z wersjami wcześniejszymi i późniejszymi, bez dokonywania zmian innych niż nazewnictwo plików i ich wersje:

# pobieramy i montujemy ISO jako filesystem
wget http://downloads.sourceforge.net/project/systemrescuecd/sysresccd-x86/2.3.1/systemrescuecd-x86-2.3.1.iso
mkdir -p /media/system
mount systemrescuecd-x86-2.3.1.iso /media/system -o loop

# zawartość pliku ISO jest dostępna w /media/system # kopiujemy z System Rescue CD jego kernel i initrd
cp /media/system/isolinux/rescuecd /tftpboot/nbi_img/rescuecd
cp /media/system/isolinux/rescue64 /tftpboot/nbi_img/rescue64
cp /media/system/isolinux/initram.igz /tftpboot/nbi_img/initram.igz.systemrescue

#Kopiujemy plik obrazu systemu do naszego domyślnego serwera http.
cp /media/system/sysrcd.dat /srv/www/htdocs/sysrcd.dat
cp /media/system/sysrcd.md5 /srv/www/htdocs/sysrcd.md5

# sprawdzamy czy mamy uruchomiony serwer http:
chkconfig -l apache2
apache2 0:off 1:off 2:off 3:on 4:off 5:on 6:off
 
# Uwaga, - krok opcjonalny jeżeli poprzedni krok zwrócił nam same 'off'
yast2 -i apache2
chkconfig --add apache2

# testujemy nasz serwer http
wget http://172.16.0.1/index.html

--2011-10-14 18:04:49-- http://172.16.0.1/index.html
Connecting to 172.16.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 44 [text/html]
Saving to: `index.html'

100%[=====================================================================================================================================>] 
44 --.-K/s in 0s 

2011-10-14 18:04:50 (2.19 MB/s) - `index.html' saved [44/44]
# Wygląda na to iż wszystko działa ;) # Robimy kopię ustawień DRBL'a
cp -p /tftpboot/nbi_img/pxelinux.cfg/default /tftpboot/nbi_img/pxelinux.cfg/default.old
# Swoim ulubionym edytorem (gedit/mcedit/vi/ed) dokonujemy edycji pliku: 
/tftpboot/nbi_img/pxelinux.cfg/default

mcedit /tftpboot/nbi_img/pxelinux.cfg/default
# Na końcu pliku dodajemy linie:

label System Rescue CD 2.3.1
# MENU DEFAULT
# MENU HIDE
 MENU LABEL System Rescue CD 2.3.1
# MENU PASSWD
 kernel rescuecd
 append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat setkmap=pl 
 nomodeset dostartx
# TEXT HELP
# Boot System Rescue CD via network
# ENDTEXT

label System Rescue CD 2.3.1 64bit (required 400 MB or more)
# MENU DEFAULT
# MENU HIDE
 MENU LABEL System Rescue CD 2.3.1 64bit (required 400 MB or more)
# MENU PASSWD
 kernel rescue64
 append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat docache 
 setkmap=pl nomodeset dostartx
# TEXT HELP
# Boot System Rescue CD 64bit via network
# ENDTEXT

I efekt:
👁 1

👁 2
W następnym odcinku: GParted, PartedMagic, i Hiren's Boot CD ;)

👁 https://i0.wp.com/www.linuxmint.com/pictures/screenshots/katya/katya.png

Zachciało mi się migracji.

1. Przeedytuj listę źródeł:

/etc/apt/sources.list

Zmień wystąpienia ‚julia’ na ‚katya’ – zmieniamy repo Minta

Zmień wystąpienia ‚maverick’ na ‚natty’ – zmieniamy repo Ubuntu

Uwaga – ppa.launchpad.net – na dzień dzisiejszy pozostaw z maverickiem

deb http://packages.linuxmint.com/ katya main upstream import
deb http://archive.ubuntu.com/ubuntu/ natty main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ natty-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ natty-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu/ natty partner
deb http://packages.medibuntu.org/ natty free non-free

deb http://ppa.launchpad.net/badenov/ppa/ubuntu/ maverick main

2.apt-get update

3. apt-get dist-upgrade

4. Masz dużą szansę na problemy z initramfs-tools – jak poniżej:

Selecting previously deselected package linux-image-2.6.38-8-generic.
(Reading database ... 191073 files and directories currently installed.)
Unpacking linux-image-2.6.38-8-generic (from .../linux-image-2.6.38-8-generic_2.6.38-8.42_i386.deb) ...
Done.
Selecting previously deselected package linux-image-generic.
Unpacking linux-image-generic (from .../linux-image-generic_2.6.38.8.22_i386.deb) ...
Selecting previously deselected package linux-generic.
Unpacking linux-generic (from .../linux-generic_2.6.38.8.22_i386.deb) ...
Setting up initramfs-tools (0.98.8ubuntu3) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-2.6.38-8-generic (2.6.38-8.42) ...
Running depmod.
update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic
Warning: No support for locale: en_US.utf8
cp: cannot stat `/usr/lib/pango/1.6.0/module-files.d/libpango1.0-0.modules': No such file or directory
cp: cannot stat `/usr/lib/pango/1.6.0/modules/pango-basic-fc.so': No such file or directory
E: /usr/share/initramfs-tools/hooks/plymouth failed with return 1.
update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
Failed to create initrd image.
dpkg: error processing linux-image-2.6.38-8-generic (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of linux-image-generic:
 linux-image-generic depends on linux-image-2.6.38-8-generic; however:
 Package linux-image-2.6.38-8-generic is not configured yet.

Rozwiazanie: Skopiuj katalog "/usr/lib/i386-linux-gnu/pango" do "/usr/lib/"

I działa ;)

Kiedyś trafiłem na denerwujący problem – mając dostęp tylko do konsoli serwera opartego na Debianie, musiałem zbadać jaki RAID  działa na nim. Serwer oczywiście HP – co niejako pod Linuxem inklinuje użycie drivera CCISS – http://cciss.sourceforge.net/. Dodam że driver zaszyty jest we wszystkich supportowanych przez ejczpi dystrybucjach, oraz wielu nie supportowanych (Debian 5.0 bez żadnego problemu obsługuje starsze SmartArray’e).

Z pomocą przychodzi narzędzie array-info – http://sourceforge.net/projects/array-info/ dostępne razem z driverem cciss – a więc dostępne również w systemie po instalacji tegoż.

Wynik ?

serwer:/dev/cciss# array-info -d /dev/cciss/c0d0 -A
Unknown Controller id 0x409c0e11
Firmware revision : 2.84
Rom revision : 2.84
1 logical drive configured.

Logical drive 0 :
Fault tolerance : RAID 5
Size : 271.33 GiB (569018880 blocks of 512 bytes)
Status : Logical drive is ok
Spare : Not configured

Przezwyciężając lenistwo:

Część I

Część II

Część III

Część IV

Część V

Część VI

Spotkanie odbyło się planowo – poniżej snapshot prezentacji.

Filmy mam nadzieję dam radę później 😉

Kontynuując współpracę z uczelniami – w dniu 4 listopada, na Wydziale Matematyczno-Przyrodniczym KUL, sala 604 będę miał przyjemność poprowadzić spotkanie dotyczące DRBL – kolejna, bogatsza o rok doświadczeń edycja spotkania z LUMD.

Spotkanie rozpoczyna się o 18:40

Skupimy się głównie na możliwościach deploymentu i migracji wielu jednostek jednocześnie, jak również na systemie pracy terminalowej dla małych klientów (biblioteki, uczelnie itp.)

Oficjalna strona Koła Naukowego Informatyków KUL: http://kni.kul.lublin.pl/Aktualnosci.aspx

Mam nadzieję, iż tym razem uda się zamieścić film z wykładu 🙂

Zapraszam 😉