Z czasem nasze systemy się rozrastają i zaczyna brakować miejsca. Samo dołożenie dysków nie wystarczy. Potrzeba powiększyć partycję. 

W moim przypadku miałem postawiony system na darmowym VMware vSphere. Do niego poprzez iSCSI został podłączony udział dyskowy. Na tym udziale znalazł się wirtualny dysk vmdk. 

Powiększanie należy zacząć od wyłączenia wirtualnej maszyny. Następnie edytujemy jej parametry a konkretnie zwiększamy wielkość wirtualnego dysku.

W moim przypadku zwiększałem wielkość z 800 do 1000GB. Po przeklikaniu tych opcji uruchamiamy wirtualną maszynę. 

W tym momencie wpisując polecenie fdisk -l zauważymy, że dysk jest większy, jednak partycja jeszcze nie.

Aby można było zwiększyć partycję należy ją wymontować. Niestety nie da się tego zrobić jeżeli jest ona używana jako systemowa. W moim przypadku ten dysk był zamontowany jako /opt więc mogłem go spokojnie wymontować.

Działamy:

umount /dev/sdb1 (oczywiście jako root). //wymontowujemy dysk

fsck -n /dev/sdb1  //sprawdzamy system plików

fdisk /dev/sdb //uruchamiamy program do partycjonowania dysku sdb

Do dyspozycji mamy następujące komendy:

Command action

   a   toggle a bootable flag

   b   edit bsd disklabel

   c   toggle the dos compatibility flag

   d   delete a partition

   l   list known partition types

   m   print this menu

   n   add a new partition

   o   create a new empty DOS partition table

   p   print the partition table

   q   quit without saving changes

   s   create a new empty Sun disklabel

   t   change a partition's system id

   u   change display/entry units

   v   verify the partition table

   w   write table to disk and exit

   x   extra functionality (experts only)

Najpierw sprawdzamy jakie mamy partycje za pomocą (p). W moim przypadku była tylko jedna. Należy zapamiętać od którego cylindra się zaczyna. U mnie było to 2048. Koniec już nas nie interesuje ponieważ ulegnie zmianie wraz ze zmianą rozmiaru partycji.

Teraz kasujemy tą partycję za pomocą (d). Tak kasujemy ją mimo to, że mamy tam cenne dane. W kolejnym kroku tworzymy nową partycję podstawową (n) o numerze 1. Wpisujemy numer cylindra od którego ma się zaczynać (2048) oraz ostatni cylinder. W tym przypadku zostanie nam podpowiedziany ostatni możliwy. Ostatnim etapem jest zapis zmian w tablicę partycji. Wykonujemy to wciskając (w).

Przed restartem sprawdzamy system plików e2fsck -f /dev/sdb1

Oraz go powiększamy resize2fs /dev/sdb1

i jeszcze raz sprawdzamy fsck -n /dev/sdb1

Po tych operacjach możemy zrestartować nasz system.

Całość operacji przebiegła w ciągu kilku sekund. Nie napotkałem na żadną operację, która wymagałaby więcej czasu.

Gdy spotkamy się z "Błąd Usługi kopiowania woluminów w tle: nieoczekiwany błąd RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...)"

Sprawdzamy w zakładce szczegóły, który użytkownik ma z tym problem. Następnie udzielamy mu praw dla klucza rejestru HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag

Strona godna polecenia odnośnie ciekawych ustawień serwera pocztowego Zimbra - https://imanudin.net

W celu ochrony przez blokadami spamowymi dobrze jest założyć ograniczenie na ilość maili wychodzących od poszczególnych użytkowników. Poniższy opis pokaże jak ograniczyć maksymalną ilość wysyłanych wiadomości przez użytkownika naszego serwera do 100 maili/dobę.

Na początku tworzymy grupę objętą polityką poprzez Polices / Groups http://adres_serwera_zimbra:7780/webui/policy-group-main.php

Wybieramy Action / Add i nazywamy naszą grupę np. lista_kont. Następnie zaznaczamy utworzoną grupę i wybieramy Action / Members oraz Action / Add. W pozycji member wpisujemy @adres_domeny.pl

Od razu zmieniamy opcję Disabled na no.

Kolejnym krokiem jest utworzenie polityki Policies / Main oraz Action / Add z ustawieniami Name Nazwa_polityki; Priority 20; (bez średników)

Po jej utworzeniu ponownie zaznaczamy stworzoną politykę i wybieramy Action / Members

W otwarte okno wpisujemy Source %lista_kont; Destination !%lista_kont; Disabled no; (bez średników) oraz 
Source !%lista_kont; Destination any; Disabled no;

 Z bocznego menu wybieramy Quotas / Configure i Action / Add

Name Limit; Link to Nazwa_polityki; Track Sender:user@domain; Period 86400; Verdict DEFER; Data Wysłano za dużo maili; Stop processing here no; Disabled no;

Zaznaczamy nasz utworzony Limit i wybieramy Action / Limits

W otwartym oknie Add Quota Limit zaznaczamy Type Message Count; Counter Limit 200; 

Na koniec sprawdzamy czy we wszystkich utworzonych grupach znalazło się Disabled ustawione na wartość no.

Od tej chwili zaczyna się odliczanie. Liczone są tylko maile wysłane poza naszą domenę, oraz tylko maile wychodzące. Licznik jest zerowany po 86400 sekundach a więc 24 godzinach. Licznik wiadomości w ostatnim oknie należy ustawić na zadaną wartość razy 2. 

Aktualny stan liczników można zobaczyć listując plik /opt/zimbra/log/cbpolicyd.log.  W pliku po każdym wysłąnym mailu pojawi się zapis informujący o koncie email oraz aktualna quota=2.00/200 (1.0%). 

PolicyD to serwer polityki MTA. Głównym jego celem jest zwalczanie spamu. PolicyD jest wbudowany w ZCS od wersji 7. 

Aby go uruchomić wykonujemy jako user zimbra:

zmprov ms nazwa_hosta +zimbraServiceInstalled cbpolicyd +zimbraServiceEnabled cbpolicyd

Następnie jako user root włączamy WebUI:

cd /opt/zimbra/httpd/htdocs/ && ln -s ../../cbpolicyd/share/webui

i edytujemy plik /opt/zimbra/cbpolicyd/share/webui/includes/config.php aby wyglądał mniej więcej tak:

#$DB_DSN="mysql:host=localhost;dbname=cluebringer";
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";

Ostatnią rzeczą jest restart usług Zimbry i serwera Apache (jako user zimbra):

zmcontrol restart
zmapachectl restart

Dostęp do PolicyD jest poprzez adres http://adres_serwera_zimbry:7780/webui/index.php

Po instalacji Zimbra 8.6 może wystąpić problem z wysokim zużyciem procesora oraz dysków. Problemu nie rozwiązuje zwiększenie ilości zasobów serwera. Na szczęście odpowiednia modyfikacja ustawień poprawiła wydajność instalacji. 

Na początku ograniczamy ilość wątków i jednoczesnych połaczeń imap, które bardzo obciążają zasoby serwera. Każdy klient otwiera średnio 3-4 połączenia. Więc ustawienie 400 pozwala na jednoczesną pracę około 40 użytkowników. 

zmprov ms nazwa_hosta zimbraImapNumThreads 400
zmprov ms nazwa_hosta zimbraImapMaxConnections 400

Kolejnym parametrem do ustawienia jest ilość pamięci RAM jaką może zająć proces Java mailboxd. Ustawienie to należy dobrać do ilości pamięci jaką mamy zainstalowaną/przydzieloną dla naszego serwera. I tak:
- dla systemu z RAM<8GB - ustawiamy 20% wielkości pamięci,
- dla systemu z RAM=8GB - ustawiamy 25% wielkości pamięci,
- dla systemu z RAM=16GB - ustawiamy 30% wielkości pamięci,
- dla systemu z RAM=32GB - ustawiamy 35% wielkości pamięci.

zmlocalconfig -e mailboxd_java_heap_size=4096 (w przypadku ZCS7 lub nowszego)
zmlocalconfig -e mailboxd_java_heap_memory_percent=30 (w przypadku ZCS6 lub starszego)

Ostatnim elementem jest zwiększenie kolejki MTA czyli usługi Mail Transfer Agent pobierającej wiadomości za pomocą protokołu SMTP i przekazującej je na odpowiednie konto.

zmprov ms nazwa_hosta zimbraMtaMaxUse 150

"nazwa_hosta" w powyższych poleceniach oczywiście zmieniamy na nazwę zgodną z nazwą naszego serwera.

Dość częstym problem jest problem z archiwizacją danych na Rewizorze. Najczęściej jest to spowodowane nieodpowiednimi uprawnieniami do katalogu archiwizacji. Przy złej konfiguracji spotkamy się w logach z informacją

spid56  Error: 18204, Severity: 16, State: 1.
Backup  Error: 3041, Severity: 16, State: 1.

Zakładam, że archiwizację robimy z poziomu klienta a baza danych jest zainstalowana na serwerze.

Aby dokonać archiwizacji należy na serwerze utworzyć i udostępnić katalog np. C:\Backup. Dostęp do zapisu w tym katalogu powinien być przyznany użytkownikowi, na którym jest uruchomiona usługa "SQL Server" odpowiedzialna za utrzymanie bazy Rewizora. Kto jest takim użytkownikiem możemy sprawdzić poprzez przystawkę services (services.msc). Prawym klawiszem wybieramy właściwości i zakładkę logowanie. W moim przypadku jest to NT Service\MSSQL$REWIZOR. W zabezpieczeniach katalogu dodajemy tego użytkownika z prawami zapis. 

W programie archiwizator jako katalog archiwum i roboczy wskazujemy wcześniej udostępniony katalog. W moim przypadku jest to \\svmdb\Backup. 

Po tych operacjach archiwizacja powinna przebiegać poprawnie.

Chcąc zmienić ikonę favicon na stronie Sharepoint, podmieniamy plik favicon.ico znajdujący się w jednej z lokalizacji 

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\TEMPLATE\IMAGES (Sharepoint 2010)

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\IMAGES (Sharepoint 2013)

Chcąc usunąć stare kopie zapasowa z Zimbry, nie robimy tego poprzez polecenie rm. Do tego celu jest stworzone specjalne narzędzie. 

Najpierw sprawdźmy jakie mamy kopie bezpieczeństwa. Zrobimy to poleceniem zmbackupquery

Wyświetli się nam lista wszystkich kopii. Znajdziemy tam zarówno kopie pełne jak i przyrostowe (incremental). Wszystko zostanie posortowane po dacie utworzenia. 

Polecenia kasującego należy używać bardzo rozważnie, ponieważ gdy usuwamy kopię oznaczoną dzisiejszą datą, jednoczenie usuwamy wszystkie wcześniej utworzone. Polecenie za to odpowiedzialne to:

zmbackup -del nazwa_kopi_bezpieczeństwa