Pages

How to check status of software raid on Zentyal 8 (Ubuntu based)

To check the status of my raid on Zentyal File Server (Ubuntu Based) i have done this:

$ sudo cat /proc/mdstat

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
      3906884608 blocks super 1.2 [2/2] [UU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>


After that I done this:

$ sudo mdadm -D /dev/md0


and got this output:

/dev/md0:
           Version : 1.2
     Creation Time : Wed Apr 21 13:38:51 2021
        Raid Level : raid1
        Array Size : 3906884608 (3.64 TiB 4.00 TB)
     Used Dev Size : 3906884608 (3.64 TiB 4.00 TB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Dec 29 15:17:29 2025
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : beta:0  (local to host beta)
              UUID : c48f8912:a38344b0:7af60abb:170fe4d0
            Events : 70848

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1


Which points me to check it even deeper 

$ sudo mdadm -E /dev/sda1


Results:

/dev/sda1:

          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c48f8912:a38344b0:7af60abb:170fe4d0
           Name : beta:0  (local to host beta)
  Creation Time : Wed Apr 21 13:38:51 2021
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7813769216 sectors (3.64 TiB 4.00 TB)
     Array Size : 3906884608 KiB (3.64 TiB 4.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=0 sectors
          State : clean
    Device UUID : b3f9004b:c546cc67:1f3de76a:1489687f

Internal Bitmap : 8 sectors from superblock
    Update Time : Mon Dec 29 15:17:29 2025
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 63d43825 - correct
         Events : 70848

   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)


and the second drive

$ sudo mdadm -E /dev/sdb1


Results:

/dev/sdb1:

          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c48f8912:a38344b0:7af60abb:170fe4d0
           Name : beta:0  (local to host beta)
  Creation Time : Wed Apr 21 13:38:51 2021
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7813769216 sectors (3.64 TiB 4.00 TB)
     Array Size : 3906884608 KiB (3.64 TiB 4.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=0 sectors
          State : clean
    Device UUID : 338d1383:62062812:06444fb3:fc1aa8e6

Internal Bitmap : 8 sectors from superblock
    Update Time : Mon Dec 29 15:17:29 2025
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : f5ea2412 - correct
         Events : 70848

   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)


Those checks where done because a few years ago after restarting my server - which was running at this time Zentyal v7 - the software raid was broken and I had to reinstall everything and setup from scratch.

In this case - my server run 448 days without restart - after reboot everything was up and running...

Migracja Płatnika z MS Access do SQL Server cz. 3 - Migracja

Kolejna część opisu migracji Płatnika z MS Access do SQL Server.

Najpierw na serwerze SQL Server musimy wykonać następujący skrypt 

sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
GO

który włącza pobieranie danych od zdalnych dostawców OLE DB.

Po zalogowaniu się w systemie przechodzimy w zakładkę Administracja ⟶ Ustawienia bazy danych...













Pojawi nam się następujące okno:












Przechodzimy w zakładkę Baza ⟶ Migracja bazy danych

Po wybraniu tej opcji pojawi się następujace okno, gdzie zazanaczmy Microsoft SQL Server















Wprowadzamy nazwę/IP serwera oraz nazwę dla nowej bazy danych Płatnika.
Ja użyłem nazwy PlatnikSql















Teraz nastąpi pytanie o rodzaj autoryzacji wybieramy: 
Użyj do autoryzacji następującego konta użytkownika bazy SQL Server















Tutaj wprowadzamy nazwę użytkownika i hasło do połączenia z bazą danych















W kolejnym kroku mamy ponownie pytanie o rodzaj autoryzacji, ja podałem login i hasło do połaczenia z bazą danych.





























W kolejnym wybieramy metodę połączenia z bazą danych:
SQLOLEDB lub MSOLEDBSQL - ja musiałem wybrać SQLOLEDEB





























Jesli wszystko przebiegło bez żadnych problemów to powinień pojawić się następujący komunikat















Informujący o tym, że migracja danych przebiegła pomyślnie.

UWAGA!
Podczas migracji danych u mnie pojawił się komunikat o tym, że nie można skopiować danych!

Rozwiązaniem było przeniesienie pliku MDB do katalogu na serwerze, tzn. jeśli bazę access Płatnika mieliście umieszczoną w katalogu np. C:\Platnik\Baza\baza_danych.mdb to plik z bazą należy skopiować na serwer dokładnie do takiego samego katalogu.

Natomiast na forum pomocnikplatnika.pl ktoś napisał, że wgrał plik MDB do katalogu
DATA SQL Server'a - tego nie próbowałem, ale może zadziałać.

Pozostało nam już tylko podłaczyć zmigrowaną bazę do programu Płatnik.


Microsoft Sharepoint 365 - dodawanie kolumny z wersją pliku

Aby dodać kolumnę z numerem wersji pliku/katalogu w Microsoft Sharepoint, trzeba przejść do Wszystkie dokumenty ⟶ Edytuj bieżący widok


























Następnie zaznaczyć: Wersja i/lub Wersja pliku


Od tego momentu w nazwach kolumn pojawią się (w zależności od wyboru) dodatkowe kolumny




























Cheers!

Migracja Płatnika z MS Access do SQL Server cz. 2 - Instalacja SQL Server 2014 32-bit

Migrację Płatnika do SQL Server'a przeprowadziłem w kilku krokach. 


Do migracji potrzebowałem SQL Server w wersji 32 bitowej. Ostatnią wersją która jest 32bit'owa to wersja 2014, która do pobrania jest bezpośrednio ze strony Microsoftu pod tym linkiem.



Okazuje się jednak, że do poprawnej instalacji potrzebny jest Windows Powershell 2.0, który niestety w Windows 11 został wycofany w sierpniu 2025r. (link 1, link 2)


W związku z tym pojawiło się pytanie: co teraz?


Rozwiązaniem jest instalacja Windows 10 na maszynie wirtualnej i dopiero w niej instalacja Microsoft SQL Server 2014 w wersji 32 bit'owej.


Po ściągnięciu i uruchomieniu instalatora pojawia się okno w którym klikamy "New SQL Server stand-alone installation or add feature to an existing installation".

Instalacja Microsoft Server 2014 32bit


Następnie akceptujemy postanowienia licencyjne i przechodzimy dalej (Next).

Instalacja Microsoft Server 2014

Wyświetli nam się lista opcji


W kolejnym kroku ustalamy nazwę instancji

Ja ustaliłem na "PLATNIK"



Kolejny ekran pokazuje jak mają być uruchamiane usługi serwera





Na potrzeby migracji pozostawiłem domyślnie ustawienia. 

W kolejnym kroku Wybieramy sposób autoryzacji z SQL Server'em - tutaj należy wybrać metodę Mixed Authorization i ustawić hasło dla użytkownika SA



Tutaj mamy pytanie o instalacje Reporting Services - które zostawiam do Waszego rozważenia czy instalować czy nie - ja instalowałem.



































Rozpoczynamy proces instalacji


Jeśli wszystko przebiegło bez problemów to powinien nam ukazać się komunikat jak poniżej




Pozostało nam teraz tylko włączyć nasłuchiwanie na porcie 1433 w programie SQL Server Configuration Manager














oraz ustawienie regułek firewall'a aby przepuszczały ruch na portach 1433 TCP i 1434 TCP i UDP.

Po tym wszystkim można sprawdzić czy jesteśmy w stanie połączyć z naszym SQL Serverem z innej maszyny np. przez SQL Server Management Studio.

Jesli tak, możemy przystąpić do migracji Płatnika.

Migracja Płatnika z MS Access do SQL Server cz. 1 - Wstęp

Ostatnio w firmie meliśmy problem z naszym rodzimym Płatnikiem. Nie dało się zaczytać plików KEDU.

Pojawiały się komunikaty takie jak poniżej:

Płatnik - Błąd migracji danych

Płatnik - Błąd migracji danych

Płatnik - Błąd migracji danych
















Problemem okazuła się "baza danych" Microsoft Access, która pomimo reindeksacji dalej nie chciała współpracować.

Po próbach wyszukania rozwiązania, udało się je odnaleźć na forach:

forumplatnika.pl #1

forumplatnika.pl #2

pomocnikplatnika.pl

które sugerowały migrację do silnika bazy danych MS SQL Server.

Bardzo pomocne okazało się wideo na kanale pana Justyna Adamskiego. Link do wideo znajdziecie tutaj.

Proces mojej migracji będzie opisany pokrótce w linkach poniżej:

Migracja Płatnika z MS Access do SQL Server cz. 2 - Instalacja SQL Server 2014 32-bit

Migracja Płatnika z MS Access do SQL Server cz. 3 - Migracja

Migracja Płatnika z MS Access do SQL Server cz. 4 - Podłaczanie Płatnika pod SQL Server