#SUSE CLA 11 obtenu #SAP #HANA

Juste pour dire que j'ai réussi ma certification Certified Linux Administrator 11 chez SUSE.

Reste à passer une certification SAP HANA dédiée pour SAP B1.

[Suse Linux][SAP HANA] Utiliser le client Bureau à distance pour l'administration du serveur SAP HANA

En préparant ma certification CLA 1, je me suis rendu compte que Linux inclut un serveur RDP : xrdp.

Les Un*xiens pur souche crieront au scandale ... faut utiliser X11/Putty et SAP préconise XVNC.

Mais la plupart des clients SAP B1 connaissent que Windows ... le bureau à distance peut donc aider.

L'installation sur un SLES 11 est simple :

• on installe via Yast xrdp ( et ses dépendances xorg-x11-server-dmx, xorg-x11-server-rdp,  yast2-rdp )
• on active le service : # chkconfig xrdp on
• on lance le service : # service xrdp start

Puis depuis Windows, on lance le bureau à distance en le connectant au serveur SAP HANA.

On se connecte et après quelque message d'avertissement TSE, on arrive sur la mire de connexion du Suse Linux.

Après connexion on arrive sur le bureau Gnome.

A partir de là, l'installation de SAP HANA ( client, serveur ) et des outils SAP B1H sont possibles en mode graphique.

Dans mon cas, comme je travaille à distance via un autre bureau à distance j'ai amélioré les rafraichissements en supprimant l'image de fond et en la remplacement par une couleur unie.

Puis j'ai ajouté dans le fichier de configuration /etc/xrdp/xrdp.ini la commande bulk_compression=1 dans la section globals.

[globals]
bitmap_cache=yes
bitmap_compression=yes
bulk_compression=1
port=3389
crypt_level=high
channel_code=1
max_bpp=24

Concernant le port de connexion, SLES utilise le port 3389 qui est le port RDP de Windows. Si sur une autre distribution le port est modifié, il suffit de le spécifier dans la chaîne de connexion du bureau à distance.

[Securité] Faille SSL V3 #POODLE

Après Heartbleed et Shellshock, voici une faille de sécurité dans le protocole SSL V3 obsolète depuis au moins 10 ans.

Solution de résolution : désactiver son utilisation dans les clients et les serveurs.

clients : http://www.ghacks.net/2014/10/15/ssl-3-0-vulnerability-discovered-find-out-how-to-protect-yourself/

Serveurs :

• la page de Stéphane Bortzmeyer : http://seenthis.net/messages/302666

• la page askubuntu : http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566 

Pour info, pour Apache2 sur Debian, j'ai du utiliser : SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2 -SSLv3 -SSLv2

Et pour dovecot ... la correction ne fonctionne pas.

Quelqu'un à une idée ?  

 Mise à jour le 7 Novembre 2014 pour Ubuntu

Ubuntu a mis à jour le package dovecot ( dovecot 2.0.19-0ubuntu2.2 )  pour permettre de désactiver le protocole SSLv3.

La solution donnée par Stéphane Bortzmeyer fonctionne avec cette mise à jour : 

ajouter au fichier dovecot.conf 

# POODLE
ssl_protocols = !SSLv2 !SSLv3

#shellshock .... ressources

Test vulnerability ( various test case ) : https://shellshocker.net/

Bash Binary in memory still vulnerable : http://stevejenkins.com/blog/2014/09/shellshock-warning-even-after-patching-your-old-vulnerable-bash-binary-could-be-resurrected-from-memory/

Collection of exploits : https://isc.sans.edu/forums/diary/Shellshock+A+Collection+of+Exploits+seen+in+the+wild/18725

Is my website compromised : http://security.stackexchange.com/questions/68296/what-does-this-attempted-shellshock-exploit-do-and-has-my-website-been-compromi

Dons en dogecoin

Si un de mes articles vous intéresse, vous pouvez désormais me faire un don en dogecoin :-)

To the moon ...