298 private links
Une suite d'outils qui permet d'utiliser une GUI (Graphical User Interface), donc une interface graphique, pour gérer d'autres services sous GNU/Linux.
Il faudrait voir ensuite comme et sauvegarder le fichier de config, le mieux serait simplement d'avoir l'outil qui donne à copier/coller le résultat, et détaillent ce qui a été modifié, rajouté, supprimé.
À voir donc.
(via Korben http://korben.info/une-interface-pour-vos-logiciels-gnulinux.html)
Si vous avez besoin de sauvegarder des fichiers, en les mettant sur un serveur ftp distant, tout ça en tâche automatique, voici un script de mon cru (parmi tant d'autres, je n'ai pas cherché) qui peut rendre bien service :
(EDIT: Vu que les indentations ont sauté, voici une copie directe en téléchargement http://thican.net/~thican/backup-ftp.sh)
################################
!/bin/env bash
coding: utf-8
Script for saving files through FTP, to a remote host (for cron or CLI)
Thibaud CANALE
thican [at] thican [dot] net
2013-06-09
GPLv3
Parameters for FTP host (you only need to edit this 4 parameters)
hostFTP="" # "ftp.example.com"
userFTP="" # "foo"
passwordFTP="" # "bar"
remoteDir="./"; # remote directory, where to save files (like "backup")
you have to create the directory yourself.
tempIFS=${IFS};
IFS=$'\x0a\x00'; # useful to avoid problem with namefiles contening some
spaces (sic)
errorStatue=false;
Test if parameters for the connexion to the FTP host are all set.
if [ "x${hostFTP}" = "x" ] || [ "x${userFTP}" = "x" ] ||
[ "x${passwordFTP}" = "x" ]; then
echo "ERROR: at least one parameter for FTP connexion is not set. Exiting." >&2
exit 1;
fi
Test if at least one parameter is given.
if [ "x${1}" = "x" ]; then
echo "Missing arguments. Exiting." >&2
exit 2;
fi
Check if each ${args} is a regular file, to be upload to ftp server.
If yes, uploading it now.
If no, display a message error.
for args in ${@}; do
if [[ -f ${args} && ! -L ${args} ]]; then # symbolic files are ignored.
ftp -n ${hostFTP}<<END
user ${userFTP} ${passwordFTP}
put ${args} ${remoteDir:-"./"}/$(basename ${args})
bye
END
else
errorStatue=true;
echo "${args} is NOT a regular file. Skipping." >&2;
fi
done
#IFS=$'\x20\x09\x0a\x00'; # Reset of the default IFS (I don't care about the old one)
IFS=${tempIFS};
We check if ${errorStatue} containts some error.
if ${errorStatue}; then
exit 3;
fi
exit 0
################################
Ainsi, sauvegardez donc ce script dans /usr/local/bin/, par exemple, éditez donc les paramètres de connexion au serveur FTP dans le début du script, et utilisez-le avec cron, juste après vos tâches de sauvegardes automatisées.
Voilà, ce n'était pas plus compliqué que ça. :-)
(Note to myself)
Internal field separator sous GNU/Linux.
Par défaut :
% echo -n -E $IFS | hexdump -C --
00000000 20 09 0a 00 | ...|
00000004
\x20 == espace, \x09 == tabulation "\t", \x0a == nouvelle ligne "\n" et \x00 == NULL
https://fr.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange#Table_des_128_caract.C3.A8res_ASCII
(Je mets toujours du temps à retrouver ça, même si cette fois, c'est arrivé du premier coup, alors je sais qu'ici, je le retrouverai plus rapidement.)
Tiens tiens, intéressant, moi qui avait essayé Nagios assez récemment, mais m'étais cassé les dents dessus.
Ohoh, joli hack, pour utiliser un écran comme le Retina d'Apple avec un port eDisplayPort, le tout pour $70.
Peut-être bientôt une mise à jour de ce hack pour rendre ce hack plus facile à utiliser.
ENFIN !
Enfin utf-8 reconnu à sa juste valeurs, et expliqué d'une façon parfaite à tout le monde.
Attention tout de même, il faut écrire "exactement" :
-- coding: utf-8 --
oui, s'il vous plaît, n'oubliez pas de mettre un simple trait d'union '-' (le "tiret du 6") entre "utf" et "8", et le tout en minuscule.
Encore merci à Sam (et Max ;)) pour ces articles super bien écrits.
Juste une copie du texte ici :
You need to have a SSH (Secure SHell) account for this to work. If you have not yet done so, Download PuTTY for free.
Open PuTTY.
Where it says 'Host Name (or IP address)' and has a box underneath it, enter the name of your SSH host into the box.
Under 'Saved Sessions' enter a name for this connection that will help you remember it later. For example, you could call it 'SSH Proxy' so you know this will be the proxy connection.
In the 'Category:' menu on the left, expand the 'Connection' menu list if it is not expanded already. Expand the 'SSH' menu list if that one is not expanded already. Click 'Tunnels' (underneath 'SSH'). This opens the options where you will enter the settings for PuTTY to create the tunnel.
Under 'Add new forwarded port:' enter 9853
Where it says 'Destination' leave that field blank but be sure to select the 'Dynamic' option underneath it.
Click the 'Add' button to add this port.
In the 'Category:' menu on the left, click the click 'Connection'.
Where it says 'Seconds between keepalives (0 to turn off)' enter 5 in the box. This will keep your connection alive and prevent it from timing out even when you walk away from the computer for a while.
In the 'Category:' menu on the left, click 'Session' at the very top to go back to the first screen.
Click the 'Save' button to save all of the settings you just entered. Later you will not have to enter these settings again in the future, you will only need to load up your saved profile (by double-clicking it after you open PuTTY) every time you wish to connect to the proxy.
Click the 'Open' button to open the connection to the proxy.
When connected you will be asked for your username and password. Enter the username and password for your account. Once connected the tunnel is open. After you are finished using the tunnel, type logout and press Enter.
Finished. Now you can connect using any SOCKS compatible software by configuring it to use localhost as the proxy server and use port 9853. The reason why you connect to localhost and not the address of the server is because PuTTY has forwarded that port from the server to your computer. Once you connect to localhost, it sends the data right back up through the encrypted tunnel to the server. Keep in mind data that leaves the server and goes out to the Internet is not encrypted unless you are connecting to a secure web site that uses SSL encryption (https://).
Alternative method: If you use PuTTY from the command line, here is a faster way to establish the secure tunnel without having to use any of the steps above:
putty.exe -D 9853 username@sshhost and press Enter
Just replace username with your actual username and ssh.host with the address of the SSH server. When it logs in you will automatically be asked for your password. Once that is accepted the encrypted tunnel is automatically created on port 9853 on your computer.
Another neat trick for command line users: Rename PuTTY.exe to ssh.exe. Move the newly renamed file to c:\windows. From then on, all you have to do to establish the tunnel from Windows is click 'Start --> Run...' to open the 'Run' dialogue box and then type ssh -D 9853 username@sshhost and press Enter. Replace username with your real username and ssh.host with the address of the SSH host.
Parce que je ne retrouve jamais ces commandes, voilà, je sais qu'ici, je m'en souviendrai :
free -m
sync && echo 3 > /proc/sys/vm/drop_caches
Il se peut que vous avez une machine hébergeant un service (prenons le cas simple du service Web), mais derrière un NAPT.
Du coup, vous ne pouvez pas accéder directement à votre service sur cette machine, sans devoir configurer ce NAPT.
Or, vous avez accès à un serveur distant, avec un service sshd.
"Super, ça va être facile", vous dites-vous -- en tout cas, c'est ce que je me suis dit -- car vous connaissez l'option -R, pour remote.
Et c'est là qu'on se rend compte qu'il suffit simplement de (re)lire le man (man 1 ssh) pour voir que déjà, il y a la réponse à nos question :
sous l'option -R [bind_address:]port:host:hostport
(Note : remarquez le contre sens qu'il y a entre la première phrase, et la troisième...) « By default, the listening socket on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)). »
Ainsi, je détaille un peu :
Dans le fichier de configuration du service sshd sur le serveur distant (souvent /etc/ssh/sshd_config), il faut activer l'option GatewayPorts avec la valeur "clientspecified" :
GatewayPorts clientspecified
Et sur la machine qui héberge le service derrière le NAPT, faites donc :
ssh user@server_distant -N -R *:<port_serveur>:localhost:<port_service_web>
serveur_distant représente le nom de domaine ou l'adresse IP du serveur qui n'est pas derrière le NAPT.
'*', c'est pour indiquer sur quel interface et/ou adresse écouter du serveur distant ; on peut donc spécifier 0.0.0.0 pour écouter sur toutes les adresses IPv4, [::] pour uniquement les adresses IPv6, "localhost" pour écouter uniquement sur l'interface "loopback" (contrairement à ce qui est indiqué, ce n'est pas par défaut avec GatewayPorts sur "clientspecified"), ou une adresse IP spécifique. (voire si possible, à une interface spécifique, mais je n'arrive plus à remettre la main sur la RFC en question)
<port_serveur>, c'est donc le port, toujours du serveur distant qui exécute le service sshd, sur lequel vous écouterez les connexions. Ainsi, ce n'est pas forcément le port du service web configuré dans le configuration du service.
<port_service_web>, le port du service derrière le NAPT. (donc, 80 pour un service web par défaut).
Ainsi, depuis votre navigateur web, vous n'aurez plus qu'à entrer l'URL suivante :
http://serveur_distant:port_serveur/
Conclusion :
Même si vous connaissez déjà une option dans un outil (comme -R dans ssh), (re)vérifier le man, il y a sûrement la solution.
PS : Vérifiez aussi dans /etc/ssh/sshd_config que l'option AllowTcpForwarding est sur "yes" (ce qui est par défaut)
Dans la série "les problèmes que j'ai rencontrés, et qu'avoir la solution est bien pratique", je présente le problème du "parse new line" :
Concrètement, imaginez que vous devez, pour X ou Y raisons, "analyser" (venant de l'anglais "to parse" http://translate.google.fr/translate_t?q=to+parse) les "retours à la ligne" ("new line") pour les modifier en d'autres caractères (comme '\n', textuellement), un simple "sed 's/\n/mon_texte/g'" ne fonctionnera.
Ainsi, merci à StackOverFlow pour la réponse suivante :
sed ':a;N;$!ba;s/\n/mon_texte/g' mon_fichier.txt
Je copie simplement ici l'explication (principalement au cas où le lien meurt) :
This will read the whole file in a loop, then replaces the newline(s) with a space.
- create a label via :a
- append the current and next line to the pattern space via N
- if we are before the last line, branch to the created label $!ba ($! means not to do it on the last line (as there should be one final newline)).
- finally the substitution replaces every newline with a space on the pattern space (which is the whole file).
Il existe aussi tr :
tr '\n' ' ' < mon_fichier.txt
Mais tr ne remplace que par un SEUL caractère ... dommage.
Pour ceux qui veulent en savoir plus, un commentaire un peu plus bas explique bien mieux http://stackoverflow.com/a/7697604
Si comme moi -- j'étais jeune et insouciant … -- vous ne comprenez pas pourquoi certaines de vos règles iptables ne fonctionnent pas (celles qui n'arrivent pas à bloquer certains maudits botnets qui continuent toujours et encore de vous spammer le port SSH), voici le rappel de la règle d'or d'iptables -- et d'autres outils utilisant les ACL mêmes -- et une commande en bash pour pouvoir ban simplement et facilement une adresse IP :
La règle d'or, c'est celle-ci :
les règles sont lues de haut en bas, et dès qu'une règle correspond à aux informations du paquets, iptables redirige vers la cible. POINT.
Alors, ce n'est pas forcément clair tout de suite, mais on va détailler avec un exemple :
Disons qu'à l'heure actuelle, vous aviez cette configuration :
iptables --list --numeric --verbose (ou -L -nv)
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
5771 442K ACCEPT all -- lo 0.0.0.0/0 0.0.0.0/0
771K 99M ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DROP all -- 1.2.3.4 0.0.0.0/0
0 0 DROP all -- 8.8.8.8 0.0.0.0/0
69993 5147K fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
5765 483K ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
2107 118K ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:22
432 458K ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:25
51 2604 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:80
0 0 REJECT all -- * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 5 packets, 820 bytes)
pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
pkts bytes target prot opt in out source destination
69914 5142K RETURN all -- 0.0.0.0/0 0.0.0.0/0
Je ne vais pas détailler ici les différentes règles, ce sont celles de base, plus fail2ban pour SSH.
Disons que vous souhaitez bloquer l'adresse IP 16.32.64.128 ; sur le web, on trouve :
iptables -A INPUT -s 16.32.64.128 -j DROP
Pour un résultat :
…
432 458K ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:25
51 2604 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 ctstate NEW tcp dpt:80
0 0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
0 0 DROP all -- 16.32.64.128 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
…
Or, problème : si la machine derrière l'IP 16.32.64.128 tente de se connecter au service web, sur le port 80, la 9ème règle répondra donc d'abord à la requête avec la 11ème (en dernière place donc), qui, cette dernière, spécifiait de bloquer complètement tout le trafic en provenance.
Conclusion, c'est l'échec.
Pour résoudre ça, il faut donc que notre nouvelle règle se retrouve avant d'autres règles qui joueraient en sa faveur.
Cette solution existe : c'est l'option --insert (-I, --insert chain [rulenum] rule-specification), à la place de --append (-A),
avec [rulenum] qui indique le numéro de la ligne où la nouvelle règle s'écrira avant (man 8 iptables explique bien mieux que moi).
Du coup, oubliez "iptables -A INPUT -s 16.32.64.128 -j DROP", et faites place à "iptables -I INPUT 3 -s 16.32.64.128 -j DROP"
avec "3", la position de la nouvelle règle, donc juste après "771K 99M ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED". (à adapter à vos besoins bien sûr !)
Ainsi, pour se simplifier la tâche, nous pouvons donc créer cette fonction en bash pour ainsi BAN simplement une adresse ip :
function ban() {
mode=${2:-"DROP"}
iptables --table filter --insert INPUT 3 --source $1 --jump $mode
}
et ça fonctionne comme ça :
ban ip_à_ban
Simple, non ?
Bien sûr, ceux qui l'ont remarqué peuvent spécifier une deuxième option (nommée mode), qui par défaut est DROP, comme REJECT, voire ACCEPT même ; ainsi, en spécifiant ACCEPT, vous pouvez de cette façon autoriser complètement une adresse IP, la vôtre par exemple, lorsque sur un serveur distant, vous voulez ne pas être bloqué par votre firewall ;) (tout le contraire de ban ^^')
C'est magique ! :D
Toujours agaçant de rechercher cette information, alors je vais la mettre ici :
NOTE : Avec la version d'iptables 1.4.16.3 (en tout cas, supérieur à 1.4.12), le module "state" (par exemple dans "--match state --state <state>") devient obsolète, et est donc remplacé par le module "conntrack", donc pour équivalent, faites --match conntrack --ctstate <state> (voir iptables-extensions(8)). Ainsi, je mets donc les commandes pour la nouvelle version.
L'interface reliée au net sera notée WAN, et celle qui permet donc de relier les machines qui n'ont pas accès au net, sera appelée LAN.
--table nat --append POSTROUTING --out-interface WAN --jump MASQUERADE
--table filter --append FORWARD --in-interface WAN --out-interface LAN --match conntrack --ctstate RELATED,ESTABLISHED --jump ACCEPT
--table filter --append FORWARD --in-interface LAN --out-interface WAN --jump ACCEPT
Ah oui, et bien sûr, il faut activer le transfert de paquets :
Pour du temporaire, jusqu'au prochain reboot : echo 1 > /proc/sys/net/ipv4/ip_forward
Mais sinon, ça se passe dans /etc/sysctl.conf : net.ipv4.ip_forward = 1
(Remarquez la ressemblance entre la hiérarchie net/ipv4/ip_forward et la variable net.ipv4.ip_forward, cela peut vous donner des idées sur certaines config si vous ne trouvez pas d'infos sur le web ;))
Article de Wikipedia : https://en.wikipedia.org/wiki/Network_Address_and_Port_Translation
Autre source, utilisant les mêmes règles : https://serverfault.com/questions/431593/iptables-forwarding-between-two-interface#431607
Comme je le pense, afficher les dates relatives comme "il y a 3 min" ou "il y a 10 jours" lors que l'on fait une capture d'écran est une mauvaise idée.
Du coup, au minimum, afficher la date absolu et la date relative entre parenthèses.
(via SebSauvage)