Konfiguracja niektórych serwerów apache nie pozwala na stosowanie skrótowego znacznika początku skryptu '<?' zamiast pełnego (np. dla skryptów php znacznikiem otwierającym jest '<?php'). Efektem może być wyrzucenie do klienta treści skryptu, zamiast wyniku jego działania.
Linie zawierające sam znacznik można szybko odnaleźć za pomocą "extended" grep:
egrep -r '<\?\s*$' ./*
opcja 'r' odpowiada za wyszukiwanie rekursywne. Zastosowane tu wyrażenie regularne dopasowuje wszystkie wystąpienia '<?', po których wystąpi dowolną ilość razy lub nie wystąpi w ogóle znak biały (spacja, tabulator itd.), a potem koniec linii.
Pozostałe wystąpienia (z dowolnym tekstem w tej samej linii) można znaleźć następująco:
egrep -r '<\? ' ./*
Pytanie dlaczego nie działa egrep '<\?\s+' ./*?
TODO: wyrażenie regularne obejmujące oba przypadki
Polecenie wydruku w vim:
:hardcopy
lub krócej
:ha
(Uwaga: "print" służy do wyświetlenia na ekranie wybranego zakresu wierszy
:[range]p[rint] ).
Tu pojawia się problem. Jeśli vim działa w trybie "mulitbyte encoding" (czyli np. edytowany jest plik z kodowaniem znaków UTF-8), niestety nie będzie potrafił poprawnie wypuścić polskich czcionek (czy to wina vima czy ps-a?) i podstępnie przekonwertuje kodowanie na ISO8859-1. Jedynym wyjściem jest ustawienie jawnej konwersji przy wydruku na ISO8859-2
:set penc=ISO8859-2
Na marginesie
Ustawienie drukarki
:set pdev=Nazwa_drukarki_w_systemie
bez tego zostanie użyta drukarka domyślna systemu.
W Debianie i pochodnych (np. Ubuntu) są dwa pakiety zawierające polecenie arping: arping i iputils-arping. Polecenie z pierwszego pakietu wspiera "pingowanie" hostów w ethernetowej domenie broadcastowej po adresie mac, z drugiego nie (pingowanie hosta możliwe jest tylko po adresie ip).
Z opisów pakietów:
Oba pakiety są ze sobą oczywiście w konflikcie.
#/etc/init.d/mysql stop # mysqld_safe --skip-grant-tables & # mysql -u root mysql> use mysql; mysql> update user set password=PASSWORD(”nowe_haslo”) where user=’root’; mysql> flush privileges; mysql> quit # /etc/init.d/mysql stop # /etc/init.d/mysql start # mysql -u root -p
Wzięte z: http://www.high-net.eu.org/ustawienie-hasla-root-do-bazy-mysql-przywrocenie-hasla-zapomnianego.html
debian:~# echo "pl_PL.UTF-8 UTF-8" > /etc/locale.gen
debian:~# echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
debian:~# locale-gen
Generating locales (this might take a while)...
pl_PL.UTF-8... done
en_US.UTF-8... done
Generation complete.
debian:~# echo "pl_PL.UTF-8" > /etc/environment
debian:~# echo "pl_PL.UTF-8" > /etc/default/locale
debian:~# locale
LANG=pl_PL.UTF-8
LC_CTYPE="pl_PL.UTF-8"
LC_NUMERIC="pl_PL.UTF-8"
LC_TIME="pl_PL.UTF-8"
LC_COLLATE="pl_PL.UTF-8"
LC_MONETARY="pl_PL.UTF-8"
LC_MESSAGES="pl_PL.UTF-8"
LC_PAPER="pl_PL.UTF-8"
LC_NAME="pl_PL.UTF-8"
LC_ADDRESS="pl_PL.UTF-8"
LC_TELEPHONE="pl_PL.UTF-8"
LC_MEASUREMENT="pl_PL.UTF-8"
LC_IDENTIFICATION="pl_PL.UTF-8"
LC_ALL=
Jeśli apache nie widzi pełnodomenowej nazwy serwera i wypisuje przy restarcie lub przeładowaniu błąd:
apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
trzeba dodać nazwę hosta i pełną domenę do pliku /etc/hostname
#echo "moj-serwer.moja-domena.com" > /etc/hostname
i wymusić wczytanie do działającego systemu tej nazwy
/bin/hostname -F /etc/hostname
Teraz także polecenie hostname powinno zwrócić fully qualified domain name (fqdn) serwera
Jeśli przy restarcie lub przeładowaniu apache wypisze ostrzeżenie:
apache2: Could not reliably determine the server's fully qualified domain name, using moj-serwer.moja-domena.com for ServerName
trzeba wyedytować plik /etc/hosts i dodać do niego wpis z adresem serwera i jego fqdn, np:
127.0.0.1 localhost
192.168.1.123 moj-serwer.moja-domena.com
W linuksie, w jądrach >=2.6, zastosowano udev. Wynikiem zastosowanych domyślnie reguł udev jest utrzymywanie informacji w systemie o karcie sieciowej, której już nie ma. Ideą takiego podejścia było zapewnienie, by tymczasowo utracone z jakiegoś powodu urządzenie nie powodowało zamieszania w systemie (np. na ruterze automatyczne "przesunięcie" po awarii nazw interfejsów sieciowych może spowodować bardzo nieprzyjemne skutki). Niezawsze jest to jednak korzystne.
Jeśli zostanie wymieniona karta sieciowa, to system rozpozna ją jako nową i udev nada jej nową nazwę (np. stara karta była nazwana eth0, to nowa zostanie nazwana eth1). By skasować informacje o starej karcie należy wyedytować plik /etc/udev/rules.d/[tu_będzie_jakiś_numer]_persistent-net.rules (np. w Debianie Lenny to: /etc/udev/rules.d/z25_persistent-net.rules) i przypisać nowej karcie odpowiednią nazwę.
Przykładowy plik:
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
# # You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1e:8c:d7:61:4f", NAME="eth0"
# PCI device 0x1186:0x4c00 (skge)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:95:c0:26:d9", NAME="eth1"
W tym wypadku, by "wymienić" starą kartę na nową należy skasować (lub zahaszować) linię dotyczącą karty o adresie sprzętowym 00:1e:8c:d7:61:4f i dla nowej karty zamienić w NAME "eth1" na "eth0".
Ostatnio ktoś mnie zapytał jak można w shellu wylistować jedynie podkatalogi, bez pokazywania plików, z bieżącego katalogu - jak wiadomo proste ls wyświetla (prawie) wszystko. Pierwszą moją myślą było użycie do tego celu polecenia find:
find ./ -maxdepth 1 -type d
czyli w bieżącym katalogu wyszukaj wszystkie obiekty typu "katalog" (ang. directory) i w poszukiwaniach nie schodź głębiej niż 1 poziom.
Czy można jednak krócej?
Tu przypomniałem sobie, że ls ma opcję "-d", której opis w man-ie brzmi:
-d, --directory
list directory entries instead of contents, and do not dereference symbolic links
Użycie
ls -d
wyświetli po prostu ".", jako oznaczenie bieżącego katalogu, a np.
ls -d /home
wyświetli /home
ale już
ls -d */
wykona to, o co chodziło, czyli pokaże tylko (nie ukryte) podkatalogi z bieżącego katalogu. "Gwiazdka" zostanie zinterpretowana przez powłokę jako "każda, występująca w katalogu nazwa" (uwaga: wpisanie ls */ spowoduje wyświetlenie zawartości podkatalogów). W zasadzie nie trzeba ograniczać się jedynie do bieżącego katalogu. Można wpisać dowolną ścieżkę przeszukiwania, byle tylko zakończyć ją "*/", np.
ls -d /home/cantek/public_html/*/
pokaże wszystkie podkatalogi z /home/cantek/public_html, i to właśnie w formie z całą ścieżką.
A jak wyświetlić listę wierszami i z dodatkowymi informacjami? Wykorzystać opcję "długą" polecenia ls:
ls -ld */
A jeśli nie potrzeba dodatkowych informacji, a jedynie wyświetlenia nazwy każdego podkatalogu w jednym wierszu? Opcja "1" w tym pomoże:
ls -1d */
Padło jeszcze jedno pytanie: Jak obliczyć, ile jest podkatalogów w bieżącym katalogu? Tu samo "ls" nie wystarczy, trzeba przesłać jego wynik potokiem do polecenia "wc" (word count):
- w wersji krótkiej
ls -d */ | wc -w
czyli "wc" liczy słowa z linii, którą otrzymał z polecenia "ls"
- w wersji dłuższej
ls -ld */ | wc -l
lub
ls -1d */ | wc -l
czyli "wc" liczy ilość linii, które otrzymał z polcenia "ls".
P.S. Aby wyświetlić tylko ukryte katalogi trzeba dodać kropkę przed oznaczeniem katalogów:
ls -d .*/
Dwa i pół tygodnia temu uruchomiłem nowy serwis poznańskiej polonistyki. Przy ogólnej liczbie ok. 10 tys. wejść pierwsza dziesiątka wg statystyki przeglądarek wygląda następująco:
| Przeglądarka | % | Ilość |
|---|---|---|
| Mozilla Firefox 2.0.0.7 | 30.36% | 3492 |
| MS Internet Explorer 6.0 | 30.13% | 3465 |
| Mozilla 5.0 | 10.68% | 1228 |
| MS Internet Explorer 7.0 | 7.56% | 869 |
| Nieznany (e) | 4.20% | 483 |
| Opera 9.23 | 2.61% | 300 |
| Mozilla Firefox 1.5.0.12 | 1.70% | 195 |
| Mozilla Firefox 2.0.0.4 | 1.33% | 153 |
| Mozilla Firefox 2.0.0.6 | 1.06% | 122 |
| Opera 9.10 | 0.93% | 107 |
Serwis odwiedzają głównie studenci polonistyki, a więc osoby uważane powszechnie za "nietechniczne". Tym bardziej więc cieszy fakt, że w rankingu (zwłaszcza, jeśli posumować różne wersje) prowadzą przeglądarki alternatywne w stosunku do, jeszcze niedawno, jedynie panującego "niebieskiego e". Czyżby wzrost świadomości w społeczeństwie?
P.S. Ranking systemów operacyjnych
| System operacyjny | % | Ilość | Uwagi |
|---|---|---|---|
| Windows XP | 73.92% | 8501 | |
| _A_UNKNOWN | 14.15% | 1627 | jakieś boty czy niekulturalne systemy operacyjne? |
| Windows 98 | 3.63% | 418 | |
| Windows Longhorn | 3.09% | 355 | |
| Windows 2000 | 2.35% | 270 | |
| Linux | 1.77% | 203 | hmm, ktoś jeszcze, poza mną, używa linuksa... |
| Mac OS X | 0.82% | 94 | |
| Windows 2003 | 0.22% | 25 | |
| Debian | 0.04% | 5 | ten Debian nie przyznaje się do swoich korzeni ;-) No, chyba, że ma Hurd'owe jajko |
| Windows 95 | 0.02% | 2 | ktoś tego jeszcze używa? Pewnie w bibliotece ze starodrukami |
| Sun Solaris | 0.01% | 1 |
Rano, w drodze do pracy, dostałem SMS-a: Serwer terminali nie żyje. Pingi nie idą.
No, to mam zajęcie od świtu, a myślałem, że zdążę się kawy napić, zanim dzień rozpocznie się na dobre.
Zaraz więc wchodzę do serwerowni i widzę - zasilanie jest, serwer leży. Sprawdzam kabelki - wszytko O'K. Nie pozostało nic innego, jak uruchomić maszynę
Tylko co się stało? Jakiś włam? Kiedy serwer stanął na nogi zacząłem przeszukiwać logi, i znalazłem:
16:14:18 localhost gnome-power-manager: Hibernating computer because the DBUS method Hibernate() was invoked
czyli nie włamywacz, ale któryś z użytkowników "zamroził" mi serwer, ale jak? Z terminala?
Krótka wizja lokalna i faktycznie, przy zamykaniu sesji użytkownicy mają do wyboru "Wyloguj", "Przełącz użytkownika", "Zablokuj ekran" i nieszczęsne "Hibernuj".
W pierwszym odruchu chciałem zablokować możliwość hibernacji w /etc/acpi, ale poczytawszy nieco dowiedziałem się, że gnome-power-manager komunikuje się bezpośrednio z HAL-em i acpi nie ma tu nic do gadania. Musi być jakiś inny sposób.
Pogooglowałem trochę i znalazłem taką informację. Po prostu jest błąd w Ubuntu, a jedynym rozwiązaniem jest odinstalowanie gnome-power-manager lub dla każdego użytkownika indywidualnie w gconf-editor odznaczenie opcji "can-hibernate" w gałęzi /apps/gnome-power-manager, wówczas użytkownik nie będzie miał w okienku zamykania przycisku "Hibernuj".
Zdecydowałem się na to drugie rozwiązanie, bo odinstalowanie gnome-power-manager pociąga za sobą z powodu zależności deinstalację np. gnome-session, a gnome-session... itd.
Należy mieć nadzieję, że, zgodnie z zapowiedzią pojawi się patch, bo przy większej instalacji LTSP, ustawianie każdemu opcji can_hibernate na "false" może być cokolwiek uciążliwe.