gim.org.pl is down || odświeżony jogger (v.0.4) GiMa

Jakiś czas temu potrzebowałem napisać małą aplikację, która pozwoliłaby mi na wysyłanie maili poprzez MS Exchange 2007. Udostępnie on po SOAPie api które się zwie EWS (Exchange Web Services)

Głównym celem było zrobienie tego możliwie szybko.
Najpierw próbowałem biblioteki do obsługi SOAPa w pythonie python-suds.
Po kilku problemach na wstępie (których już dokładnie nie pamiętam) i chwili googlania, znalazłem coś co się zwie suds-ews, czyli teoretycznie suds ze wsparciem dla EWS.

Z tego co pamiętam dorzucając python-ntlm i korzystając potem z suds.transport.windows udało się nawet połączyć z serwerem exchange'a, ale wyglądało na to, że ten suds-ews, niezbyt obsługuje typy tablicowe, które EWS sobie definiuje, a przynajmniej ja nie miałem pojęcia jak z nich skorzystać.

Skończyło się na tym, że odpaliłem Visuala i napisałem krótki program, który robi to co trzeba.
Najpierw trzeba wygenerować Proxy, można to zrobić przy użyciu narzędzia wsdl, ja to robiłem z poziomu Visuala, opis jest tutaj.
Istotna informacja, która dla SOAPowców pewnie jest dość oczywista, dla mnie nie była :> : przy tworzeniu Proxy w Visualu należy podawać ścieżkę do /EWS/Services.wsdl, a w kodzie ściężkę do /ews/Exchange.asmx

Nie ukrywam, że nie znam C#, ale mając przykłady napisanie aplikacji nie było zbyt problematyczne.
Celowo wykomentowałem własny callback do sprawdzania certyfikatu, głównie po to, by móc odpalić to pod mono (o tym za chwilę) bez konieczności weryfikacji CRL.
Aplikacja jako argument bierze nazwę pliku który będzie wysłany, pierwsza linijka jest traktowana jako temat wiadomości, dodatkwo potrzebuje pliku config.txt o skomplikowanej postaci:

• recipients = one@foobar.com, two@foobar.com

Kod jest tu: Ews.cs.
Należy sobie zmodyfikować usera, hasło, domenę i hostname w CreateBinding() (Wszystkie metody są statyczne, bo jak już wspomniałem, jestem leniwy ;p).

Próbowałem wygenerować Proxy, używając narzędzia wsdl, które przychodzi z mono, ale aktualnie nie działa, bug odnośnie tego wisi półtora roku.
Jeżeli jednak mamy Proxy wygenerowane w Visualu, to można powyższą aplikację skompilować i odpalić w mono

• mono-csc -r:System.Web.Services.dll Ews.cs Web\ References/ExchangeWebServices/Reference.cs

Certyfikat który przychodzi z serwera, nie musi zawierać certyfikatu root'a, więc najlepiej jest dodać ręcznie certyfikat dla CA, którym podpisany jest certyfikat serwera Exchange. W moim przypadku Thawte Premium Server CA

• wget https://www.thawte.com/roots/thawte_Premium_Server_CA.pem -O root.cer
• certmgr -add -c Trust root.cer
• mono Ews.exe listaOdbiorcow.txt

Rozszerzenie certyfikatu ma znaczenie, certmgr, nie łyknie rozszerzenia .pem

A friend of mine, had a problem today (with Python) which voils down to the following piece of code:

• f = open('input.txt')
• c = f.readlines()
• # here were different operations
• # on c, but that's not really important
• print len(c)

Don't ask why there is readlines() in the first place, that's not the problem.
The problem was, that c had wrong number of lines. However answer to that lies in python's documentation:

Read until EOF using readline() and return a list containing the lines thus read. If the optional sizehint argument…

Unfortunatelly the file contained some random bytes, among different bytes there was also character with hex value of 0x1A. Now let me quote everyone's favourite source of information - wikipedia:

In the MS-DOS operating system, this character is used to indicate the end of a file or the end of user input in an interactive command line window. This behavior was borrowed from the earlier CP/M operating system.

Some operating systems such as the pre-VMS DEC operating systems, along with CP/M, tracked file length only in units of disk blocks and used Control-Z (SUB) to mark the end of the actual text in the file. For this reason, EOF, or end-of-file, was used colloquially and conventionally as a TLA for Control-Z instead of SUBstitute.

There is simple "solution" to this problem:

• f = open('input.txt', 'rb')

Since CP/M was mentioned twice here, I can't resist to quote famous words of a man I've always regarded as a brilliant visionary - Gary Kildall (but unfortunately rather poor businessman for that matter) (the quote relates to int 21h/AH=09h):

"Ask Bill [Gates] why the string in function 9 is terminated by a dollar sign. Ask him, because he can't answer, only I know that."

As I've mentioned a while ago, I try to use powershell (1.0) on daily basis.

Recently I had strange problem regarding Execution Policy.

I've started powershell as admin, executed Set-ExecutionPolicy RemoteSigned. Then I've started powershell under console2 as a normal user.
To my suprise running Get-ExecutionPolicy returned Restricted

First explanation, solution below: I'm running 32bit version of Console2 on x64 version of vista. Since console2 starts powershell, it's also treated* as a 32bit application, so requests to HKLM\Software\ because of WOW64 goes to HKLM\Software\Wow6432Node.
These are totally independent registry keys, so when I've started powershell as Admin, changing execution-policy, changed only the first key (since powershell.exe is a 64bit application).
*Edit: Of course under console2, 32bit version of powershell is also started due to WOW64.

Solution is pretty simple, start Console2 as Admin, and then change execution policy.
Hope that helps anybody ;)

Zdaje się, że od XP 'Save As' i 'Open' pamiętają folder, gdzie ostatnio się pracowało. Jest to dość irytujące w z zachowaniem, do którego większość się chyba przyzwyczaiła, gdzie dialogi te startują w aktualnym katalogu.

Żeby to zmienić w Viście, wystarczy odebrać sobie prawa do odczytu klucza: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\comDlg32\LastVisitedPidlMRU. To pewnie nie jest najlepszy sposób, ale dla aplikacji z których korzystam DZIAŁA :P

Zastanawiam się, dlaczego nie wygooglałem tego wcześniej: Speed up powershell startup

At work I try to use powershell just to learn at least a few things about it. Of course I could use zsh, bash or any other unix shell, but that would be no fun, would it?

Pokaż więcej...

Do zapamiętania:
PS> $env:path
PS> $env:path = $env:path + ";c:\blah"

Mój znajomy (pozdrowienia dla Wacława!) po reinstalacji Windowsa XP, miał problemy z dyskiem. Wacek, miał dwie partycje na NTFSie i dwie FATowe. XP nie widział jednego dysku na facie. Pierwsza moja myśl była taka: Hmm, może xp, zmienił typ partycji z 0xc (FAT32 (lba)) na 0x1c (hidden fat32), (taka myśl stąd, że kiedyś miałem taki przypadek).

No więc bootujemy linuxa, sprawdamy, ale nie, fdisk pokazuje normalnie. Ściągnąłem więc na Windowsie genialny (i opensource'owy!) program testdisk autorstwa Christophe'a Grenier'a (służy on do odzyskiwania partycji, ja jednak wykorzystuję go conajmniej w jednym innym celu).
Włączamy testdiska, a on pokazuje, że dysk ma 137GB... (Ci którzy wiedzą o co chodzi, pewnie się dziwią, że jeszcze się nie zorientowałem co jest grane) hmm, coś jest nie tak, ponieważ znajomy nie znał, a ja nie zapamiętałem, bootujemy ponownie linuxa, żeby sprawdzić, ile jego dysk ma cylindrów i wracamy do testdiska... zmieniamy w geometry rozmiar z około 16800 na 30401, zapuszczamy testdiska i co? i właśnie za cylindrem ok 16800 występują błędy odczytu...

W tym momencie przyszło mi do głowy, że pewnie coś z LBA, sprawdziliśmy w biosie, możliwe tylko dwie opcje, auto, albo disabled. No to wracamy do windy, chwila googlania i mamy odpowiedź.
Najpierw znaleźliśmy informację, że 28-bitowe adresowanie LBA ogranicza rozmiar dysku do ~ 137 GB
Otóż Cudowny i Wspaniały System Operacyjny, domyślnie nie obsługuje 48-bitowego adresowania dysków LBA!
Na zamkniętym już ponoć msinfo.pl, znaleźliśmy informację, na temat LBA i windowsa xp. Otóż po pierwsze musi być zainstalowany SP 1. Nie mam na co dzień do czynienia z Windows, więc nawet nie wiedziałem, gdzie się sprawdza, że SP jest zainstalowany... Po drugie, w kluczu: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Atapi\Parameters trzeba dodać, wartość:
EnableBigLba i ustawić ją na 1.
Niewiele myśląc, tak też zrobiliśmy, reboot i TA DAM, działa :)
Nigdy nie zrozumiem tego systemu :]

Jeszcze małe wyjaśnienie i kilka obliczeń dla ciekawych...

• Dokładniej, to było 16709, gdyż: 160709*255(głowice)*63(sektory)=268430085 sektory
• 1 << 28 = 268435456 (maksymalna liczba sektorów, możliwa do obsłużenia przy 28bitowym adresowaniu...)
• 30401*355*63=488392065 (ilość sektorów dysku Wacława...)
• no i jeszcze: 488392065*512 (ilość bajtów na sektor) / 1000^3 (1000 bo wyliczamy to co podają producenci, ^3, bo chcemy GB) = 250
• a i jeszcze: (1 < < 28)*512 / 1000^3 = 137 oczywiście...

Chociaż IE7 mam już od jakiegoś czasu, dopiero teraz przyszło mi do głowy stestować jedną rzecz, a mianowicię obsługę XMLHttpRequest.
Stworzyłem więc na szybko stronę do testowania IE7, tworzącą prosty request i działa bez problemu pod IE7, możecie stestować :-).
Później sprawdziłem google i o tym ficzerze informowano już w styczniu (huh I'm obsolete! :-]) na msdnowym blogu ie.

Grzegorz Niemirowski suggested, that I should provide script, that I've described lately.
So here is automated script for Microsoft Power Shell.

You've probably heard about Microsoft PowerShell. This small note will show you how to analyze (well at least start to analyze) Windows PE executable files with just use of PowerShell.

Pokaż więcej...

Zapomniałem o tym wspomnieć, ale pociągnąłem sobie Debugging tools for Windows (32-bit ver, ~14M) oraz Windows Symbol Packages (dla Win XP z SP2, 195M).
Owo 195M zdekompresowało się do 834M (sic!), niezła kompresja :-), fakt, że sporo tam bajtów 0, ale jakoś ostatnio nie miałem do czynienia z niczym _uzytecznym_ coby miało taki stopień kompresji :).