Więcej na www.googlezeitgeist.com
Jest też podsumowanie tego co oglądano najczęściej na YouTube.
Lista najczęściej oglądanych dostępna na:
Wednesday, December 28, 2011
Podsumowanie roku przez Google
Już coroczny przegląd statystyk wyszukiwania i tego co się wydarzyło w mijającym roku 2011.
Więcej na www.googlezeitgeist.com
Jest też podsumowanie tego co oglądano najczęściej na YouTube.
Więcej na www.googlezeitgeist.com
Jest też podsumowanie tego co oglądano najczęściej na YouTube.
Monday, December 26, 2011
Konfiguracja maszyny wirtualnej na KVM
KVM jest coraz atrakcyjniejszym rozwiązaniem oferującym wirtualizację, do tego jest standardowo w jadrze systemu Linux, więc nic nie musimy dodatkowo instalować.
Do pełnej wirtualizacji lepiej nadają się systemy uniksowe, jeżeli chcesz wirtualizować systemy z rodziny Windows niezbędne będzie użycie sterowników parawirtualizowanych dla systemu Wondows jako gościa.
Dlatego KVM świetnie nadaje się do wyrtualizacji serwerów Linux. Jeżeli chcesz postawić serwer WWW w bezpiecznym środowisku, czy zbudować wirtualną sieć z serwerami Linux, KVM jest świetnym rozwiązaniem.
W końcu, co najważniejsze, to zanosi się na to, że KVM ma szansę stać się w najbliższej przyszłości numerem 1 wśród rozwiązań wirtualizacyjnych dla platformy Linux. Więcej informacji na ten temat można znaleźć na stronie Open Virtualization Alliance oraz na stronie projektu www.linux-kvm.org.
Przedstawię w jaki sposób używać KVM. Ponieważ używam dystrybucji Debian, będzie to sposób konfiguracji charakterystyczny dla tego systemu, tzw. "Denian's way". Co prawda określenie to odnosi się głównie do konfiguracji sieci, ale może również kojarzyć się z nieużywaniem specjalnych narzędzi tworzonych przez Red Hat, takich jak Virsh.
Pierwsze co musimy przygotować to wirtualne karty sieciowe dla naszych gości. Do tego trzeba zbudować most, tworzący wirtualny przełącznik, którego co najmniej jeden port będzie rzeczywistym interfejsem sieciowym. Dzięki niemu będziemy przekazywać połączenia między siecią wirtualną a rzeczywistą. Oczywiście sposobów konfiguracji może być wiele, my zakładamy, że host gości będzie miał połączenie z internetem.
Do stworzenia mostu musimy mieć zainstalowaną paczkę bridge-utils, chyba że w naszym systemie dostępne jest już polecenie brctl. Sam most będziemy tworzyć poprzez modyfikację pliku /etc/network/interfaces, a nie brctl.
Natomiast do stworzenia wirtualnych interfejsów, które mamy zamiar później dołączyć do mostu
być może potrzebna jeszcze będzie paczkę vtun, jeżeli jeszcze jej nie mamy. Po instalacji tej paczki należy ręcznie zamontować jej moduł: modprobe tun. W przyszłości system podczas startu załaduje go sam. Do zarządzania tymi interfejsami będzie nam jeszcze potrzebne narzędzie tunctl, które zawiera paczka uml-utilities.
Teraz możemy już przystąpić do konfiguracji interfejsów, więc odpalamy w vim'e plik /etc/network/interfaces i z przykładowej konfiguracji:
Teraz należy zresetować sieć skryptem /etc/init.d/networking i sprawdzić czy istnieją wszystkie interfejsy tap (polecenie ifconfig) oraz czy poprawnie został stworzony most i dodane do niego interfejsy. Dla konfiguracji, którą przedstawiłem wynik polecenia brctl show powinien być następujący:
Do pełnej wirtualizacji lepiej nadają się systemy uniksowe, jeżeli chcesz wirtualizować systemy z rodziny Windows niezbędne będzie użycie sterowników parawirtualizowanych dla systemu Wondows jako gościa.
Dlatego KVM świetnie nadaje się do wyrtualizacji serwerów Linux. Jeżeli chcesz postawić serwer WWW w bezpiecznym środowisku, czy zbudować wirtualną sieć z serwerami Linux, KVM jest świetnym rozwiązaniem.
W końcu, co najważniejsze, to zanosi się na to, że KVM ma szansę stać się w najbliższej przyszłości numerem 1 wśród rozwiązań wirtualizacyjnych dla platformy Linux. Więcej informacji na ten temat można znaleźć na stronie Open Virtualization Alliance oraz na stronie projektu www.linux-kvm.org.
Przedstawię w jaki sposób używać KVM. Ponieważ używam dystrybucji Debian, będzie to sposób konfiguracji charakterystyczny dla tego systemu, tzw. "Denian's way". Co prawda określenie to odnosi się głównie do konfiguracji sieci, ale może również kojarzyć się z nieużywaniem specjalnych narzędzi tworzonych przez Red Hat, takich jak Virsh.
Pierwsze co musimy przygotować to wirtualne karty sieciowe dla naszych gości. Do tego trzeba zbudować most, tworzący wirtualny przełącznik, którego co najmniej jeden port będzie rzeczywistym interfejsem sieciowym. Dzięki niemu będziemy przekazywać połączenia między siecią wirtualną a rzeczywistą. Oczywiście sposobów konfiguracji może być wiele, my zakładamy, że host gości będzie miał połączenie z internetem.
Do stworzenia mostu musimy mieć zainstalowaną paczkę bridge-utils, chyba że w naszym systemie dostępne jest już polecenie brctl. Sam most będziemy tworzyć poprzez modyfikację pliku /etc/network/interfaces, a nie brctl.
Natomiast do stworzenia wirtualnych interfejsów, które mamy zamiar później dołączyć do mostu
być może potrzebna jeszcze będzie paczkę vtun, jeżeli jeszcze jej nie mamy. Po instalacji tej paczki należy ręcznie zamontować jej moduł: modprobe tun. W przyszłości system podczas startu załaduje go sam. Do zarządzania tymi interfejsami będzie nam jeszcze potrzebne narzędzie tunctl, które zawiera paczka uml-utilities.
Teraz możemy już przystąpić do konfiguracji interfejsów, więc odpalamy w vim'e plik /etc/network/interfaces i z przykładowej konfiguracji:
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp
auto eth0tworzymy coś takiego:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet manual
# RouterOS
iface tap0 inet manual
pre-up tunctl -b -u grzesiek
pre-up ifconfig tap0 up
post-down tunctl -d tap0
# Fedora 16
iface tap1 inet manual
pre-up tunctl -u grzesiek -t tap1
pre-up ifconfig tap1 up
post-down tunctl -d tap1
# CentOS 6
iface tap2 inet manual
pre-up tunctl -u grzesiek -t tap2
pre-up ifconfig tap2 up
post-down tunctl -d tap2
# CentOS 6 x86_64
iface tap3 inet manual
pre-up tunctl -u grzesiek -t tap3
pre-up ifconfig tap3 up
post-down tunctl -d tap3
iface br0 inet static
address 10.0.0.1
netmask 255.255.255.0
gateway 172.16.16.101
broadcast 10.0.0.255
network 10.0.0.0
bridge_ports eth0 tap0 tap1 tap2 tap3
bridge_maxwait 0
bridge_stp off
bridge_fd 0
auto eth0To moja przykładowa konfiguracja na laptopie. Zmieniamy konfigurację eth0 na manual, natomiast całą konfiguracje wpisujemy dla br0, naszego nowego mostu. Jak widzimy do tego mostu należą eth0, tap0, tap1, tap2, tap3. Każdy interfejs tapX jest oddzielny dla każdego hosta, w ich konfiguracji należy zmienić nazwę użytkownika, z jakim prawami jest tworzony nowy interfejs. W moim przypadku jest to "grzesiek".
auto tap0
auto tap1
auto tap2
auto tap3
auto br0
Teraz należy zresetować sieć skryptem /etc/init.d/networking i sprawdzić czy istnieją wszystkie interfejsy tap (polecenie ifconfig) oraz czy poprawnie został stworzony most i dodane do niego interfejsy. Dla konfiguracji, którą przedstawiłem wynik polecenia brctl show powinien być następujący:
Teraz możemy sobie wybrać jakąś lokalizacje na przechowywanie obrazów i stworzyć obraz przykładowym poleceniem: qemu-img create -f raw routeros.raw 800M.
bridge name bridge id STP enabled interfaces
br0 8000.72a5b61e39bf no eth0
tap0
tap1
tap2
tap3
To polecenie stworzy obraz dysku o nazwie routeros.raw i rozmiarze 800 MB.
Następnie dla wygody tworzymy skrypt, który skonfiguruję zaporę dla wirtualnych hostów, aby przekazywać im połączenie internetowe:
#!/bin/sh
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -d 0/0 -j MASQUERADE
Nie zapomnij włączyć przekazywania pakietów, odkomentuj linię net.ipv4.ip_forward=1 w pliku /etc/sysctl.conf i wydaj polecenie sysctl -p. Reguły te przekazują połączenie przez interfejs bezprzewodowy do sieci wirtualnej. Możemy dla wygody zapisać ten skrypt pod nazwą network.sh w katalogu, w którym będziemy przechowywać obrazy wirtualnych hostów i uruchamiać przed korzystaniem z nich. Oczywiście można dodać go do /etc/rc.local aby system robił to automatycznie.
Kolejnym krokiem jest stworzenie skryptu dla każdego hosta, tu przykładowy dla RouterOS:
#!/bin/sh
# -boot d z cdrom
kvm -hda /virt/routeros.raw -cdrom /virt/iso/mikrotik-5.8.iso -boot c -m 256 -net nic,macaddr=DE:AD:BE:EF:24:13 -net tap,ifname=tap0 -enable-kvm -smp 1 -daemonize & #-nographic
Skrypt zapisujemy pod nazwą routeros.sh i za jego pomocą uruchamiamy wirtualny host. Watro wyjaśnić znaczenie poszczególnych opcji:
-hda - wskazuje na dysk host
-cdrom - wskazuje na obraz płyty w wirtualnym napędzie
-boot - decyduje o kolejności botowania, c oznacz dysk z opcji -hda, z oznacz obraz z -cdrom
-m - ilość pamięci przeznaczonej dla hosta
-net nic,macaddr - definiuje adres MAC interfejsu hosta
-net tap,ifname - wskazuje wirtualny interfejs przeznaczony dla danego hosta
-smp - ilość rdzeni przeznaczony dla hosta
-daemonize - uruchamia hosta w trybie demona, nie wyświetla jego terminalu w bieżącym, dzięki temu host może pracować jako serwer i nie blokować terinala
-nographic - nakazuje nie wyświetlać okna z monitorem hosta
Jeżeli pierwszy raz uruchamiamy hosta z pustym dyskiem i chcemy zainstalować system z obrazu to opcję -boot ustawiamy na d, po instalacji na c. gdy już skonfigurujemy ustawiania sieci w hoście i uzyskamy dostęp zdalny możemy użyć opcji -nographic, aby nie wyświetlał się zbędny ekran serwera.
Gdyby maszyna wirtualna się nie uruchomiła należy sprawdzić, czy mamy załadowane moduły kvm oraz dla procesorów Intel kvm_intel, a dla AMD kvm_amd. Oczywiście jeżeli procesor wspiera wirtualizację wszystko powinno działać bez zarzutu.
Wednesday, November 2, 2011
Dzień z życia (Life in a Day)
Z 4500 godzin przesłanych nagrań powstał 90-minutowy film dokumentalny. To pierwszy film tego typu, od 31 października 2011 r. dostępny jest już na YouTube.
O filmie: http://www.filmweb.pl/film/Dzie%C5%84+z+%C5%BCycia-2011-593899
Pełen film dostępny pod adresem http://youtu.be/JaFVr_cJJIY
Tuesday, November 1, 2011
Obsługa HTTP Pipelining w Chrome 17
Pipelining to technologia przyśpieszająca działanie protokołu HTTP, została wprowadzona wraz z wersją HTTP/1.1. Pozwala na niesekwencyjne wysyłanie zapytań do serwera w ramach jednej sesji TCP. Dla odróżnienia Keep-Alive daje już duże przyśpieszenie, a pozwala na sekwencyjne wysyłanie zapytań w ramach jednej sesji. Apache wspiera obie metody. Z kolei Firefox wspiera, ale domyślnie jest to wyłączone. Opera jest obecnie jedyną przeglądarką, która to wspiera domyślnie.
Teraz Chrome będzie wspierać tą funkcję. Aby lepiej zrozumieć jej znaczenie polecam zapoznać się z stroną: http://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-pipelining/
Najzabawniejsze jest to, że technika Pipelining istnieje od 1999 w RFC 2616.
http://code.google.com/p/chromium/issues/detail?id=8991
Teraz Chrome będzie wspierać tą funkcję. Aby lepiej zrozumieć jej znaczenie polecam zapoznać się z stroną: http://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-pipelining/
Najzabawniejsze jest to, że technika Pipelining istnieje od 1999 w RFC 2616.
http://code.google.com/p/chromium/issues/detail?id=8991
Capsicum - nowy sposób na izolację procesów
Capsicum, tak nazywa się nowe rozwiązanie opracowane w laboratorium Uniwersytetu Cambridge przy finansowym wsparciu firmy Google. Celem projektu jest kompleksowe rozwiązanie problem z bezpieczeństwem przeglądarki Chrome i systemu operacyjnego Chrome OS.
Capsicum to tzw. sandbox framework, który rozszerza POSIX API. Jego użycie wymaga zmiany kodu w aplikacjach. Poza tym jest to rozwiązanie na poziomie aplikacji, póki co, bo biblioteka dopiero się rozwija.
Capsicum to tzw. sandbox framework, który rozszerza POSIX API. Jego użycie wymaga zmiany kodu w aplikacjach. Poza tym jest to rozwiązanie na poziomie aplikacji, póki co, bo biblioteka dopiero się rozwija.
Na początek wprowadzono ją do nowego wydania FreeBSD 9.0, ale Google ma w planach przeportowanie go na system Linux.
W publikacjach na temat Capsicum (http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf) wspomina się o tym, że użyta technika rozwiązuje wszystkie problemy w przeciwieństwie do swoich konkurentów, w tym do SELinux. Pojawia się pytanie, czy Capsicum wyprze SELinux?
Okazuje się, że nie koniecznie, pisze o tym Robert Watson, jedne z developerów Capsicum:
> How is Capsicum positioned, from user & admin perspective, when compared to > the MAC work on FreeBSD and SELinux on Linux? Is one the superset of > another, will one obsolete another? This is a point addressed in some detail in the paper, which considers the relationship between Capsicum and other security models. Capsicum is really addressed at the application author, whereas MAC models are typically addressed at a blend of system integrators and system administrators. As a result, users mostly benefit from Capcisum transparently.
Ponadto jeden z deweloperów SELinux w swojej notatce poświęconej konkurencji ze strony Capsicum stwierdza, że z technicznego punku widzenia nie ma powodu, który nie pozwalałby na działanie obu tych technologi na tym samym systemie. To ważny fakt, ponieważ można się w sieci natknąć na takie informacje.
Rozwiązanie użyte w projekcie Capsicum jest o tyle prostsze, że nie wymaga administrowania w przeciwieństwie do SELinux, gdzie np. zmiana konfiguracji Apache może pociągnąć za sobą konieczność zmiany polityki SELinux, a ta wymaga już ponownego uruchomienia serwera.
Jednak z ogólnego punktu widzenia Capsicum wcale nie jest antidotum na wszystkie problemy związane z bezpieczeństwem. Capsicum nie można użyć do kontroli np. współpracy różnych części systemu.
Trzeba pamiętać, że jest to rozwiązanie problemu z bezpieczeństwem przeglądarki internetowej, które może mieć szersze zastosowanie, a nie odwrotnie. Zresztą jak Russell Coker zauważył, deweloperzy Capsicum ogłaszają, że stworzyli coś nowego ale nie zależy im na tym, aby to propagować.
Strona projektu: http://www.cl.cam.ac.uk/research/security/capsicum/
Trzeba pamiętać, że jest to rozwiązanie problemu z bezpieczeństwem przeglądarki internetowej, które może mieć szersze zastosowanie, a nie odwrotnie. Zresztą jak Russell Coker zauważył, deweloperzy Capsicum ogłaszają, że stworzyli coś nowego ale nie zależy im na tym, aby to propagować.
Strona projektu: http://www.cl.cam.ac.uk/research/security/capsicum/
Wednesday, October 5, 2011
Testowanie wydajności serwera Apache
Posiadasz serwer HTTP Apache, który po prostu działa i nigdy wcześniej nie musiałeś przejmować się kwestią wydajności, aż do dziś? Jeżeli tak to przyda Ci się narzędzie do testowania wydajności serwera HTTP.
Ten wpis nie jest o tym, jak poprawić wydajność serwera Apache czy MySQL, lecz o tym jak przetestować maksymalne obciążenie serwera Apache oraz pośrednio bazy danych i skryptów PHP. Niemniej jednak wspomnę o pewnych ustawienia dot. wydajności tych serwerów.
Więc, gdy już staniesz przed zadaniem polegającym na oszacowaniem, czy Twój serwer sprosta określonemu zadaniu czas zapoznać się z co najmniej jednym narzędziem przeznaczonym to testowania jego wydajności. Ponieważ mowa tu o konkretnym serwerze jakim jest Apache, to najlepszym wyborem będzie narzędzie ab (skrót od ApacheBench).
ApacheBench możemy zainstalować w systemie Debian instalując paczkę apache2-utils. Dobrze jest te same testy wykonać bezpośrednio z samego serwera (czyli testujemy sam serwer) oraz ze zdalnego hosta, gdzie do testu wydajności serwera zostanie wkomponowana wydajność łącza, którym posługuje się serwer.
Najciekawszymi opcjami programu ab są parametry:
-c - określa ilość jednoczesnych zapytań
-t - określa czas trwania testu
-n - określa całkowitą ilość zapytań, które mają zostać wysłane
Serwer można testować na różne sposoby. Możemy kazać mu obsłużyć np. 2 tyś. zapytań i patrzeć ile mu to zajmie czasu (z określaniem ilości maksymalnych połączeń lub bez). Taki test ma następująca składnię:
ab -c 150 -n 200 <adres serwera>
Wynik takiego testu odpowie na pytanie ile czasu zajmie dla serwera obsłużenie 200 zapytań przy założeniu, że maksymalna ilość jednoczesnych zapytań nie będzie większa niż 150.
Z przedstawionego wydruku wynika, że 27 sekund.
Drugim sposobem testowania może być test, który sprawdza ile zapytań serwer zdoła obsłużyć np. w czasie 3 minut przy założeniu, że maksymalna ilość jednoczesnych połączeń nie będzie większa niż 300. Oto przykład:
ab -c 300 -t 300 <adres serwera>
Oczywiście podane w przykładach obciążenia są przesadzone, chyba że posiadasz bardzo dobre łącze.
Poza ab watro również zainteresować się programem httperf, który potrafi wykonywać testy z obciążeniem podobnym do rozkładu Poissona oraz http_load. Ten ostatni pod Debianem należy samemu skompilować.
http://httpd.apache.org/docs/2.0/programs/ab.html
http://www.hpl.hp.com/research/linux/httperf/
http://acme.com/software/http_load/
Ten wpis nie jest o tym, jak poprawić wydajność serwera Apache czy MySQL, lecz o tym jak przetestować maksymalne obciążenie serwera Apache oraz pośrednio bazy danych i skryptów PHP. Niemniej jednak wspomnę o pewnych ustawienia dot. wydajności tych serwerów.
Więc, gdy już staniesz przed zadaniem polegającym na oszacowaniem, czy Twój serwer sprosta określonemu zadaniu czas zapoznać się z co najmniej jednym narzędziem przeznaczonym to testowania jego wydajności. Ponieważ mowa tu o konkretnym serwerze jakim jest Apache, to najlepszym wyborem będzie narzędzie ab (skrót od ApacheBench).
ApacheBench możemy zainstalować w systemie Debian instalując paczkę apache2-utils. Dobrze jest te same testy wykonać bezpośrednio z samego serwera (czyli testujemy sam serwer) oraz ze zdalnego hosta, gdzie do testu wydajności serwera zostanie wkomponowana wydajność łącza, którym posługuje się serwer.
Najciekawszymi opcjami programu ab są parametry:
-c - określa ilość jednoczesnych zapytań
-t - określa czas trwania testu
-n - określa całkowitą ilość zapytań, które mają zostać wysłane
Serwer można testować na różne sposoby. Możemy kazać mu obsłużyć np. 2 tyś. zapytań i patrzeć ile mu to zajmie czasu (z określaniem ilości maksymalnych połączeń lub bez). Taki test ma następująca składnię:
ab -c 150 -n 200 <adres serwera>
Wynik takiego testu odpowie na pytanie ile czasu zajmie dla serwera obsłużenie 200 zapytań przy założeniu, że maksymalna ilość jednoczesnych zapytań nie będzie większa niż 150.
grzesiek@home:~$ ab -c 150 -n 200 http://abc.defgh.pl/sklep/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking abc.defgh.pl (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests
Server Software: Apache
Server Hostname: abc.defgh.pl
Server Port: 80
Document Path: /sklep/
Document Length: 4180 bytes
Concurrency Level: 150
Time taken for tests: 27.192 seconds
Complete requests: 200
Failed requests: 0
Write errors: 0
Total transferred: 929000 bytes
HTML transferred: 836000 bytes
Requests per second: 7.36 [#/sec] (mean)
Time per request: 20393.908 [ms] (mean)
Time per request: 135.959 [ms] (mean, across all concurrent requests)
Transfer rate: 33.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 56 652 1002.6 189 3453
Processing: 1039 14081 7456.0 16816 26197
Waiting: 991 10618 5224.2 12306 21415
Total: 1100 14733 7740.0 19039 26429
Percentage of the requests served within a certain time (ms)
50% 19039
66% 20760
75% 21232
80% 21387
90% 22152
95% 23612
98% 23821
99% 24356
100% 26429 (longest request)Drugim sposobem testowania może być test, który sprawdza ile zapytań serwer zdoła obsłużyć np. w czasie 3 minut przy założeniu, że maksymalna ilość jednoczesnych połączeń nie będzie większa niż 300. Oto przykład:
ab -c 300 -t 300 <adres serwera>
Oczywiście podane w przykładach obciążenia są przesadzone, chyba że posiadasz bardzo dobre łącze.
Poza ab watro również zainteresować się programem httperf, który potrafi wykonywać testy z obciążeniem podobnym do rozkładu Poissona oraz http_load. Ten ostatni pod Debianem należy samemu skompilować.
http://httpd.apache.org/docs/2.0/programs/ab.html
http://www.hpl.hp.com/research/linux/httperf/
http://acme.com/software/http_load/
Wednesday, September 21, 2011
Czerwony znak zachęty dla konta root
W SUSE Linux Enterprise podpatrzyłem fajne ustawienie, a mianowicie chodzi o zmianę koloru znaku zachęty tzw. prompt po zalogowaniu się na konto root. Jest to o tyle przydatne, że dostajemy wzrokowe ostrzeżenie przypominające nam o tym, aby od tego momentu uważać co się robi.
Oczywiście wcześniej to robiłem, ale jak zwykle czas sprawia, że człowiek zapomina jak to się robi i gdy chce to zrobić ponownie na innym systemie ponownie szuka. Dlatego muszę to sobie zapisać.
Dla konta root modyfikujemy plik /root/.bashrc:
#export PS1='\h:\w\$ '
export PS1='\[\033[1;31m\]\h:\w\$\[\033[0m\] '
Oczywiście wcześniej to robiłem, ale jak zwykle czas sprawia, że człowiek zapomina jak to się robi i gdy chce to zrobić ponownie na innym systemie ponownie szuka. Dlatego muszę to sobie zapisać.
Dla konta root modyfikujemy plik /root/.bashrc:
#export PS1='\h:\w\$ '
export PS1='\[\033[1;31m\]\h:\w\$\[\033[0m\] '
Pierwsza pogrubiona sekwencja znaków określa jak ma być kolorowany tekst ale nie określa kiedy należy zaprzestać kolorowania. Za to odpowiada ostatnia pogrubiona sekwencja, dzięki niej reszta wprowadzonego tekstu w terminalu nie jest kolorowana. Podkreślona jedynka sprawia, że znak zachęty jest pogrubiony, zero w tym miejscu oznaczałoby brak pogrubienia.
Jak i co znajdziemy tu:
Subscribe to:
Posts (Atom)