Ostatnio spotkałem się z silnikami krokowymi Japan Servo  KH56JM2U014A06 brak opisu tych stepperów spowodował przepalenie płytki arduino i stepsticków DRV8825. Aby to działało i nie paliło układów ustaliłem poniższe podłączenie.





KH56JM2U014A06

Wielokrotnie miałem problem z certyfikatami przypisanymi do IP. Jednak od jakiegoś czasu dostępne jest SNI (Server Name Indication) czyli możliwość rozpoznawanie certyfikatu po nazwie. Metoda nie działa dla bardzo starych przeglądarek ale w zasadzie nikt już z nich nie korzysta.

Przykład z proxy dla Apache 2.2

NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine on SSLProxyEngine On SSLCACertificateFile /etc/ssl/certs/ca_bundle.crt SSLCertificateFile /etc/ssl/certs/cetyfikat.crt SSLCertificateKeyFile /etc/ssl/private/klucz-certyfikatu.key DocumentRoot /var/www/ RewriteEngine On # Apache 2.4 może wymagać tych dyrektyw
# RequestHeader set X-Forwarded-Proto "https" # RequestHeader set X-Forwarded-Port "443" ServerName www.twojadres.pl ServerAlias twojadres.pl RewriteCond %{HTTPS} off RewriteRule (.*) https://www.twojadres.pl$1 [R,L] AllowEncodedSlashes On ProxyRequests Off ProxyPreserveHost On <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / https://ip_za_proxy:443/ nocanon ProxyPassReverse / https://ip_za_proxy:443/
</VirtualHost>

Przykład dla zwykłego VirtualHosta Apache 2.2

NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine on SSLProxyEngine On SSLCACertificateFile /etc/ssl/certs/ca_bundle.crt SSLCertificateFile /etc/ssl/certs/cetyfikat.crt SSLCertificateKeyFile /etc/ssl/private/klucz-certyfikatu.key DocumentRoot /var/www/ RewriteEngine On # Apache 2.4 może wymagać tych dyrektyw
# RequestHeader set X-Forwarded-Proto "https" # RequestHeader set X-Forwarded-Port "443" ServerName www.twojadres.pl ServerAlias twojadres.pl RewriteCond %{HTTPS} off RewriteRule (.*) https://www.twojadres.pl$1 [R,L] </VirtualHost>

Działające przeglądarki:
Mozilla Firefox 2.0 lub nowsze
Opera 8.0 lub nowsze  (z włączonym TLS 1.1)
Internet Explorer 7.0 lub nowsze (na Windows Vista, nie na XP)
Google Chrome
Safari 3.2.1 na Mac OS X 10.5.6 lub nowszym

Pierwsza sprawa to wykonać stop backup CT jako gzip (tar.gz)
Kopię przenosimy na nowy serwer proxmox 4.x do katalogu /var/lib/vz/lxm/dump
Kopię przywracamy na ProxMox'ie 4.x jak zwykłą i mamy gotowy kontener LCX. Twraz wystarczy skonfigurować sieć i cieszyć się migracją.

Często spotykany problem podczas konfiguracji DTC w połączeniu postfixa i maildropa to komunikat:

(temporary failure. Command output: ERR: authdaemon: s_connect() failed: Permission denied /usr/bin/maildrop: Temporary authentication failure.)

Najlepszym i najszybszym sposobem na sprawdzenie czy wszystko jest ok to ustawienie uprawnień na wykonanie jednorazowego pliku poczty do Maildir. 

# ls -al /usr/bin/maildrop

 

-rwsr-xr-x 1 root mail /usr/bin/maildrop bit UID właściciela w chwili doręczenia/wykonania czyli "s" rozwiązuje problem praw innego użytkownika do katalogu Maildir. Powodzenia. 

Najlepszą formą przygotowania jądra do instalacji jest przygotowanie pakietu.