Wojciech Błaszkowski

po zakupie nowego lapa (DELL Vostro 1500) przyszła pora na wyrzucenie domyślnie zainstalowanej visty home i zainstalowanie PLD.
mały problem z WiFi został szybko rozwiązany specami autorstwa arekm.

dzięki temu uruchomienie całości zprowadza się do:
- zbudowania bcm43xx-fwcutter.spec
- zainstalowanie powyższego
- zbudowania bcm43xx-firmware.spec
- zainstalowania powyższego
- usunięcia bcm43xx (jeśli udev już go wrzucił)
- załadowania bcm43xx

karta wifi:
0c:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)
dmesg po załadowaniu drivera i podniesieniu sieci zeznaje:
bcm43xx: Chip ID 0x4311, rev 0x1
bcm43xx: Number of cores: 4
bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
bcm43xx: PHY connected
bcm43xx: Detected PHY: Analog: 4, Type 2, Revision 8
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx: Radio turned off
bcm43xx: Radio turned off
Device driver eth1 lacks bus and class support for being resumed.
bcm43xx: PHY connected
Device driver 0000:0c:00.0 lacks bus and class support for being resumed.
Device driver 0000:0c:00.0 lacks bus and class support for being resumed.
Device driver 0000:0c:00.0 lacks bus and class support for being resumed.
Device driver 0000:0c:00.0 lacks bus and class support for being resumed.
bcm43xx: Microcode rev 0x127, pl 0xe (2005-04-18 02:36:27)
bcm43xx: Radio turned on
bcm43xx: Radio enabled by hardware
bcm43xx: Chip initialized
bcm43xx: 32-bit DMA initialized
bcm43xx: Keys cleared
bcm43xx: Selected 802.11 core (phytype 2)
ADDRCONF(NETDEV_UP): eth1: link is not ready
bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0
bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0
bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0
bcm43xx: set security called, .level = 0, .enabled = 0, .encrypt = 0
SoftMAC: Open Authentication completed with xx:xx:xx:xx:xx:xx
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
bcm43xx: set security called, .active_key = 0, .level = 2, .enabled = 1, .encrypt = 1
bcm43xx: set security called, .enabled = 1, .encrypt = 1
eth1: no IPv6 routers present


Kolejny router jaki dostałem w swoje łapki. Model o którym mowa dostarczony został przez jedną z chojnickich firm ISP do domu moich rodziców kilka miesięcy temu, więc trzeba sprawdzić co jest w środku rzeczonego pudełka.

Logowanie do panelu (monter ISP nie ustawił hasła !) przebiegło standardowo, po porcie 80.
nmap zeznał (MAC umyślnie zmieniony):

# nmap 192.168.2.1

Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-22 16:09 CEST
Interesting ports on 192.168.2.1:
Not shown: 1695 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
MAC Address: XX:XX:XX:XX:XX:XX (Unknown)


Więc trzeba będzie zalogować się również via ssh, ale to później.

Router pracuje jako gateway dla PPPoE. Mamy tu możliwość wyrzucenia sieci w powietrze z kodowaniem WPA2 (z czego oczywiście skorzystałem), firewall, DDNS, port forwarding (wiele modeli innych firm nadal tego nie ma !), traffic control (podział łącza). Moją szczególną uwagę w menu GUI zwróciła opcja Management -> System Command. Polecenie uname nie przyniosło niestety spodziewanego rezultatu, więc trzeba było spróbować zalogować się na porcie 22. Problemem było hasło. Rozwiązanie proste i szybkie: wykorzytujemy wiersz poleceń dostępny w GUI i wpisujemy:

cat /etc/passwd

na co dostajemy odpowiedź:

root:$1$$oCLuEVgI1iAqOA8pwkzAg1:0:0:root:/:/bin/sh
nobody:x:99:99:Nobody:/:

google zdradzają, że:

$1$$oCLuEVgI1iAqOA8pwkzAg1 = root

i hasło gotowe :)

$ ssh root@192.168.2.1
root@192.168.2.1's password:

BusyBox v1.01 (2006.03.31-16:15+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.


Zatem to podstarzała wersja BusyBox. Wnętrzności routera:

# cat /proc/cpuinfo
system type : Philips Nino
processor : 0
cpu model : R3000 V0.0
BogoMIPS : 178.99
wait instruction : no
microsecond timers : no
tlb_entries : 64
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
ll emulations : 0
sc emulations : 0

# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 14639104 12832768 1806336 0 159744 7708672
Swap: 0 0 0
MemTotal: 14296 kB
MemFree: 1764 kB
MemShared: 0 kB
Buffers: 156 kB
Cached: 7528 kB
SwapCached: 0 kB
Active: 1516 kB
Inactive: 7892 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 14296 kB
LowFree: 1764 kB
SwapTotal: 0 kB
SwapFree: 0 kB

W mojej opinii router ten to raczej udana konstrukcja. Niewielki, funkcjonalny, bezawaryjny (jak dotąd).

Wielu z nas prowadzi swoje blogi, wysyła e-maile, przegląda strony www. Często nie zastanawiamy się jednak jak wygląda to od środka – np. stawiamy pytanie: dlaczego strona www się otwiera? Postaram się przedstawić pojęcie hostingu widziane oczyma administratora.

1. określenie zakresu usług
a) interpreter dla www – Python, PHP, ASP, Java, inne.
b) bazy danych – MySQL, PgSQL, SQLite, Oracle, FireBird, inne.
c) poczta: SMTP, POP3, IMAP, antyspam, antywirus.
d) dodatki: cron (okresowe wykonywanie zadań), ssh (mozliwość wykonywania poleceń takich jak kopiowanie, usuwanie bezposrednio na serwerze).
e) backup.
f) monitorowanie usług, statystyki.
g) DNS.
h) polityka bezpieczeństwa: m.in. firewall, apparmor.

2. przeznaczenie platform serwerowych
a) pojedyncze maszyny kompleksowo obsługujące użytkowników – na jednej maszynie instalujemy wszystkie wymienione w pkt. 1 usługi.
b) rozdzielenie usług – odrębne klastry odpowiedzialne są za każdą z wymienionych w pkt. 1 usług.

3. panel zarządzania
a) autorski panel zarządzania
b) Plesk, cPanel, inne.

4. serwery, serwerownia, łącza
a) domowe data center – hosting na PC,
b) dzierżawiony hosting – serwery dedykowane u innego providera,
c) renomowane data center, własne serwery, wielokrotne łącza, własna pula IP.

Każdy z powyższych punktów w skrócie:

Dla punktu pierwszego postanawiam nie opisywać zagadnień związanych z ASP, Java, Oracle i FireBird – zostały wymienione dla pokazania zarysu usług.

Ad. 2.
Rozwiązanie 2a wydaje się prostrze do zrealizowania i z pewnością mniej kosztowne. Wadą tego rozwiązania jest to, że awaria serwera powoduje odcięcie od wszystkich świadczonych usług dla części użytkowników. Dochodzi do tego również zależność bezproblemowej pracy usług w stosunku do obciążenia serwera. Żeby nie być gołosłownym – apache będzie pracował bez zająknięcia przy loadzie 20, podczas gdy dla serwera MySQL load 6 to już katorga. Do tego pracujący cały czas system antyspamowy, który wraz z antywirusem skutecznie pożera zasoby sprzętowe.
Rasumując – rozwiązanie jest tanie na początku, kiedy nie ma zbyt wielu użytkowników, później zaczyna się kombinatorka.

Przykład 2b jest zdeydowanie bardziej kosztowny – na start potrzebujemy osobnych maszyn dla przynajmniej 3 podstawowych usług: www, baz danych, poczty. Pozostałe usługi (jak DNS czy monitoring) można dorzucić do którejś z w/w. Takie rozproszone rozwiązanie świetnie sprawdza się dla większej ilości obsługiwanych klientów. Dla przykładu – awaria serwera www pozbazwia usługi www (i tylko www !) niektórych użytkowników, np.: poczta działa dalej.

Ad. 3.
Pisanie własnego panelu zarządzania wymaga przynajmniej miesiąca przygotowań polegających na określeniu funkcjonalności owej aplikacji i sposobu jej działania, roku do 2 lat pisania kodu (2 programistów) oraz przynajmniej 3 miesięcy testów. Firmy posiadające własny (autorski) panel zarządania usługami mogą sobie pozwolić na dowolne jego modyfikacje w zależności od trendów i życzeń klientów oraz własnych pomysłów i charakteru usług. Takie modyfikacje są często, jeśli nie zawsze niedozwolone ze względu na obwarowania licencyjne czy niedostępność kodu źródłowego dla aplikacji komercyjnych. Stąd też, przykładowo przeprowadzając audyt bezpieczeństwa takich aplikacji nie jesteśmy w stanie załatać ewentualnej dziury – czekamy aż zrobi to dla nas dostawca oprogramowania, a czas spędzony na oczekiwaniach umilamy sobie żyjąc w nadzieji, że nikt z owej luki w niepowołany sposób nie skorzysta.
Warto zatem napisać własną aplikację.

Ad. 4.
Znów o kosztach. Na początek, przy niewielkiej liczbie userów, możemy sobie pozwolić na umieszczenie własnych usług wg. modelu 2a, mając na uwadze późniejszą rozbudowę platform i imigrację poszczególnych usług na odrębne maszyny – należy więc czynić odpowiednie przygotowania bazując na zamyśle rozproszenia usług. Pozwoli to zaoszczędzić na początku nieco gotówki, ale należy mieć na uwadze wady jakie niesie ze sobą to rozwiązanie. Zdecydowanie należy uwzględnić łącze, jakim będziemy dysponować – 10 Mbps (w górę i w dół) wydaje się być absolutnym minimum dla kilkudziesięciu klientów. Dla większej ilości (w tysiącach) użytkowników musimy zadbać o łącze ~50-100 Mbps i więcej, w zależności od potrzeb. Dobrym, aczkolwiek drogim rozwiązaniem jest możliwość korzystania z maksymalnej udostępnianej przez operatora przepustowości i rozliczanie się za wygenerowany ruch.

Kolejna część (postaram się w przyszły weekend) poświęcona szczegółom rozwiązań punktu 1a.

metoda:
./builder -bb kernel.spec -D –with fbsplash –without grsecurity –logtofile ../kernel-2.6.20.11.log

wyniki:
kernel-2.6.20.11-1.i686.log
kernel-2.6.20.11-1.i686.rpm
kernel-doc-2.6.20.11-1.i686.rpm
kernel-drm-2.6.20.11-1.i686.rpm
kernel-headers-2.6.20.11-1.i686.rpm
kernel-module-build-2.6.20.11-1.i686.rpm
kernel-net-rndis-2.6.20.11-1.i686.rpm
kernel-pcmcia-2.6.20.11-1.i686.rpm
kernel-sound-alsa-2.6.20.11-1.i686.rpm
kernel-sound-oss-2.6.20.11-1.i686.rpm
kernel-source-2.6.20.11-1.i686.rpm
kernel-vmlinux-2.6.20.11-1.i686.rpm

Zaczęło się od prywatnej wypowiedzi jednego z czołowych deweloperów:

W Ac to nic nie ma.

Zmartwiłem się tym trochę. Używam Ac do codziennej pracy, podobnie jak wielu z Was. Niemniej jednak w powyższej (jakże treściwej i zwięzłej) wypowiedzi jest dużo racji..

kernel - jak sobie nie zbuduję to pozostaje mi zaciągnięcie czegoś z Th.
inne pakiety - jak sobie nie zbuduję to pozostaje czekać na czyjąś litość (może zapuści na buildery i updatnie indeksy dla poldka) albo trzeba zbudować samemu.

Nie tak dawno czytałem na pld-devel-pl o unowocześnieniu Ac, z którego to w gruncie rzeczy wychodziło Th; a to ktoś modularne X chciał, a to nowe gcc, nowe glibc, etc..

Podsumowując:

Do pracy na lapie nie potrzebny mi obracający się cube przy skakaniu po pulpitach, przydałby się OpenOffice2.2.

Do platform LAMP soft można sobie samemu ze speców budować/upgradować/zmieniać/etc.. jak się samemu nie spsuje to raczej działa.

Tyle. Zaraz będzie kernel 2.6.20.11 rel 1 “dla Ac” wrzucany :)