Synchronizacja czasu z NTP

4 komentarzeMac

Maci podłączone do domeny, wszystko działa pięknie. Sprawdzamy czy działa Windows (dual-boot), restartujemy kompa pod Mac OS X. Wpisujemy login/hasło (poprawne), chwile czekamy, ekran się trzęsie i tyle. Na konto lokalne można się zalogować bez problemu tylko czas jest jakiś dziwny i przesunięty o 2 godziny.
Wiadomo, Kerberos ma rozjechany czas i przez to bilety się momentalnie przedawniają. Przyczyna rozjechania czasu też jest prosta, OS X jak każdy szanujący się system ustawia hardware clock w GMT i potem softwarowo dodaje/odejmuje czas żeby dostosować się do strefy czasowej. Windows za to ustawia hardware clock na czas lokalny.
No dobra, problem powinno nam załatwić ntp ale w /etc/ntp.conf wszystko jest skonfigurowane poprawnie i dalej nie działa.
Szybkie wstukanie
root# ntpdate
Looking for host ntp.pjwstk.edu.pl and service ntp
host found : ntp.pjwstk.edu.pl
14 Feb 14:15:05 ntpdate[1420]: the NTP socket is in use, exiting
i problem zajętego socketu :-) Szybkie śledztwo i okazuje się, że port jest zajęty przez ntpd, który powinien automatycznie synchronizować czas z serwerem ntp. Jedynym problemem jest to, że ntpd synchronizuje czas powoli małymi krokami tak żeby system nie zagubił się jak nagle wypadnie mu kilka godzin albo syslog się cofnie. Czyli może za kilka dni czas się zsynchronizuje i logowanie do AD zacznie działać :-)
Rozwiązanie jest proste :D zabić ntpd i zsynchronizować ręcznie czas z ntp.

Z Pstrykiem napisaliśmy coś takiego:

root# cat /usr/sbin/ntpupdate.sh
#!/bin/bash

/usr/sbin/ntpd
/usr/bin/killall ntpd

RET=1
TIME=15
while [ $RET -ne 0 ] && [ $TIME -gt 0 ]; do
/usr/sbin/ntpdate adres.serwera.ntp >> /var/log/ntpupdate 2>&1
RET=$?
TIME=$(($TIME-1))
sleep 1
done

Po czy do /etc/rc dopisaliśmy:

# By Pstryk & Kfaz ;)
/usr/sbin/ntpupdate.sh

Kolejny workaround, dziwny ale działający :-)
Podobno nowe sterowniki dla Windows z BootCamp poprawiają ten problem i Windows nie zmienia czasu w hardware clock

Odmontowywanie dysków Windowsowych na dual boot’ach

Mac

Scenariusz jest prosty. Maki mają triple-boot (Mac OS X, Win XP, Linux) i użytkownicy nie mogą mieć dostępu do innych partycji systemowych z poziomu Mac OS X. Chociażby po to żeby nie grzebali w plikach konfiguracyjnych, nie wyciągnęli bazy SAM czy żadnych innych rzeczy, których przeczytanie nie byłoby dla nas zbyt miłe :) Sprawa wydaje się banalnie prosta, wystarczy, tak jak w poprzednich wersjach Mac OS X, przeedytować /etc/fstab i pozamiatane. Jednak po otwarciu tego pliku okazuje się, że coś się zmieniło i pokazuje się coś takiego:
IGNORE THIS FILE.
This file does nothing, contains no useful data, and might go away in
future releases. Do not depend on this file or its contents.
i weź tu człowieku bądź mądry kiedy zamiast jednego statycznego pliku pojawia się automounter (/sbin/autodiskmount), który oczywiście jest binarką :) No dobra, ale automounter skądś jest wywoływany. W tym przypadku będzie to /etc/rc.netboot gdzie montowane są wszystkie dyski podczas instalacji. Po napisaniu kilku if’ów okazało się, że mój szczwany plan z filtrowaniem co montujemy nie zadziałał :-( a że czas naglił trzeba było to załatwić w inny sposób :-) Mały (niezbyt elegancki) workaround polega na odmontowaniu dysków kiedy automounter już je podmontuje :-D . Aby to zrobić wystarczyło w /etc/rc dopisać trzy linijki:
#odmontowanie dyskow windowsowych
umount /dev/disk0s2
umount /dev/disk0s6
Wiem, że to nie jest najsprytniejszy patent ale działa ;-)

Keyring a konto domenowe

Mac

Mój breloczek na koncie domenowym zabezpieczony jest hasłem z Active Directory, ustawienie standartowe dzięki temu mam prawie single sign-on, hasło domenowe zabezpiecza moje certyfikaty itd.
Problem pojawia się kiedy hasło domenowe się zmieni z poziomu czegoś innego niż nasz stacja pracująca pod Mac OS X. Po takiej zmianie logujemy się używając nowego hasła domenowego i zaraz po zalogowaniu musimy wpisać hasło do breloczka, które jest… naszym starym hasłem ;) Aby uniknąć tej upierdliwej czynności i logować się tylko raz należy zmienić sobie hasło do breloczka korzystając z Keyring Access. Rzecz prosta ale irytująca. Chociaż patrząc z drugiej strony w Windows jest podobny problem (utrata lokalnych certyfikatów w momencie resetowania hasła do konta lokalnego).

Przydatne narzędzia do zabawy netInfo z poziomu konsoli

Mac

Dzisiaj instalując Oracle na Mac OS X znalazłem parę fajnych narzędzi pozwalających na dostanie się do netInfo z poziomu konsoli i wpisanie wszystkiego bez latania po drzewkach w interfejsie graficzny. Super sprawa dla osób robiących coś przez SSH albo zakładających konta za pomocą skryptów.

Manipulacje na obiektach w katalogu:
Tu z pomocą przychodzi nam narzędzie nicl. Pozawala ono m.in. na tworzenie obiektów, ich kasowanie, modyfikacje, przeszukiwanie, czytanie i kopiowanie. Jeśli kiedykolwiek będziesz odtwarzać swoje netInfo z backupu to z pewnością nicl będzie do tego niezbędne. Składnia jest prosta: nicl [options] datasource [command], na przykład założenie użytkownika wygląda tak
# nicl . -create /users/loginname
# nicl . -append /users/loginnameuid 601
# nicl . -append /users/loginname gid 600
# nicl . -append /users/loginname shell /bin/bash
# nicl . -append /users/loginname home /Users/loginname
# nicl . -append /users/loginname realname "Imię i nazwisko usera"
Potem przyda się jeszcze zmienić komuś hasło:
# passwd loginname
i mamy wszystko gotowe.
Katalog domowy stworzy się sam przy pierwszym logowaniu na podstawie tego co jest w /System/Library/User Template . Z szablonami oczywiście można się pobawić ale zostawie to sobie na oddzielny wpis :)
Każdy bardziej dociekliwy może sobie poczytać o tym narzędziu wpisująć w konsoli man nicl :)

Powitanie

3 komentarzeOT, w-files

Jako, że jestem tu nowy to wypadało by jakoś zacząć i się przywitać. Ponieważ przenoszę się z innego miejsca to pozwolę sobie przerzucić notki więc proszę się nie zdziwić jak w najbliższym czasie pojawi się wysyp notek podpisanych przeze mnie, nie jestem aż tak płodny i nie zdominuję w-files swoją twórczością.
A czego możecie się po mnie spodziewać? Czym są dla mnie blogi techniczne? Myślę, że pisząc publicznie o tym co robię staram się podzielić swoimi doświadczeniami z innymi i chcę gdzieś spisać to co zrobiłem żeby potem nie robić tego od nowa, raczej nie staram się być opiniotwórczy, lansować pewnych produktów czy udowadniać wyższości A nad B (tu proszę wstawić nazwy wybranych świąt, systemów operacyjnych czy producentów procesorów)

TeraCopy i FC

tips'n'tricks, tools

ostatnio podpatrzyłem fajny tool – TeraCopy. niestety 'free for home users’ więc na firmowego lapa 15€ trzeba będzie poświęcić. jak nazwa sugeruje tool służy do kopiowania i przenoszenia plików i nie byłoby w tym nic specjalnie wyjątkowego poza ważnym szczegółem – ładnie integruje się z systemem, zastępując gówniane, systemowe kopiowanie, dodając kolejkowanie, sumy kontrolne itp, itd – a więc wszystko to, czego braqje. [ps. testuję go na w7]

za chwilę trafiłem na problem – freecommander [freeware, ostatni update o2.2k9] nadal korzysta z systemowych libów. okazuje się jednak, że da się to ładnie da się problem rozwiązać, modyfiqjąc plik ini:

standardowa lokalizacja pliq: %userprofile%AppDataRoamingFreeCommanderfreecommander.ini
należy zamknąć aplikację a następnie dodać dwie linijki:

FileMovePrg=C:Program FilesTeraCopyTeraCopy.exe Move *%ActivSelAsFile% "%InactivDir%"
FileCopyPrg=C:Program FilesTeraCopyTeraCopy.exe Copy *%ActivSelAsFile% "%InactivDir%"

[oczywiście podając odpowiednie ścieżki do teracopy]

najs end łorking (;

n.

SIP [OCS]

exchange, tips'n'tricks

SIP nie pozwala na znaki z poza standardowego alfabetu łacińskiego [na znaki diakrytyczne]. efekt może być nieco mylący, ponieważ sam interfejs nie ostrzega – podczas włączania użytkownikom funkcjonalności OCS można wybrać automatyczne tworzenie nazwy SIP domain jako imię.nazwisko@siddomain. wizard pokazuje wszystko jako 'success’ a potem zaczynają się pytania typu 'czemu po rozwinięciu adresów grupy nie widać wszystkich osób?’.
problem jest dość łatwo zdebugować, ponieważ w eventlogu na serwerze pojawiają sie warningi [nie errory] informujące, że jest problem w synchronizacji adresu SIP.
przypadek na jaki trafiłem był dość ciekawy i zacząłem debugowanie od złego narzędzia – ADSIEdit. po zmianie adresu SIP na nowy [np. z jozef.kot@domain.internal na józef.kot@domena.com], user oczywiście nie mógł zalogować się na nowy adres. sprawdziłem ADSIEditem atrybut msRTCSIP-DomainName – i wszystko niby ok. a mimo to user nadal jest w stanie zalogować się na stary adres. początkowo myślałem, że to może opóźnienie replikacji, ale nic z tego… w końcu sięgnąłem po najprostsze narzędzie – czyli eventvwr i wszystko stało się jasne.
dowodzi to:

  • żeby mimo wszystko zaczynać od podstawowych narzędzi [nawet jeśli spodziewa się poważniejszych problemów]
  • że OCS pomimo tego, że integruje się z AD i z niego sczytuje informacje to realnie korzysta z danych w SQL

niestety inne kwestie nie są takie proste do zdebugowania – zwłaszcza komunikacja pomiędzy komponentami takimi jaki Edge czy WebAccess to długie godziny ślęczenia i sprawdzania na poziomie protokołu. wszelkie odstępstwa od podręcznika okazują się generować problemy ):

n.