SSH Cheat Sheet

danidemi — Fri, 19 Feb 2010 11:39:00 +0000

Task: login to remote host with username and password

ssh -l [login] -p [port]

Task: login to remote host using a configured alias

First of all you need to configure the alias. The SSH configuration file is normlly stored in ~/.ssh/config. This is an example.

host

Hostname [hostname]
Port [port]
ForwardAgent [yes|no]
ForwardX11 [yes|no]
User [login]

Once you have an alias, you can specify the alias name instead of specify all the options as parameters.

ssh [alias]

Task: login to remote host using key authentication

Put your private key in ~/.ssh/id_rsa
Ensure nobody can access it. After all it’s your private key.
Transfer your public key in your remote host home directory
On the remote host append the public key to the list of authorized ones with the following command.
cat [public_key_file] >> ~/.ssh/authorized_keys
Pay attention to the fact that the authorized_key file should be writeable only by the owner. If you forget that, the key based authentication will definitely fail.

Task: copy a local file to a remote host

Copying file to host:

scp [local_file] [remote_user]@[remote_host]:[path]

Copy the local file “readme.txt” on your remote host folder (don’t forget the “~”) using the “john” username. Let’s suppose the remote host is called “wonderland.org”.

scp readme.txt john@wonderland.org:~

Copying file from host:

scp scp [remote_user]@[remote_host]:[remote_file_path][local_file_path]

Blogged with the Flock Browser

Affidabilità dei sistemi informatici bancari

danidemi — Mon, 09 Nov 2009 23:17:02 +0000

Stavo lavorando in una banca ad un porting verso tecnologie attuali di un sistema esistente da qualche anno. Nell’ambito di tale progetto dovevo realizzare un modulo del sistema il cui compito era sostanzialmente quello di estrarre da DB dei record con un campo data maggiore o uguale alla data di odierna, eseguire alcune elaborazioni e scriverli in un file da inviare ad un sistema a valle per una successiva elaborazione.

Il campo che conteneva la data era un campo CHAR di 8 caratteri e ci era stato assicurato che tutte le date erano nel formato YYYYMMDD. In questo modo per selezionare i record con una data maggiore di quella odierna si poteva sruttare l’ordinamento alfabetico e ad esempio scrivere una condizione del tipo

data >= '20052310'

Facendo qualche test mi sono però accorto che in realtà nel db c’erano record con date nel formato DD/MM/YY. La condizione restituiva perciò anche record con valori pari ad esempio a “23/12/98″, “20/10/89″ ed in generale qualsiasi data il cui giorno fosse maggiore o uguale a 20. Questo perchè, in ordine strettamente alfabetico, “23/12/98″ segue “20052310″. I record che avrebbero dovuto essere stati estratti erano qualche decina, invece la presenza delle date nel formato inatteso, ne faceva salire il numero a qualche centinaio.

Dopo un consulto con un programmatore che lavorava alla manutenzione del sistema decidemmo di lasciare i dati scorretti sul DB ma eliminarli nella query di selezione. E quindi in dettaglio la condizione diventò…

data >= '20052310' AND data not like '__/__/__'

Tutto sembrava andare per il meglio, il file contenente i risultati divenne molto più corto e l’elaborazione successiva ne avrebbe certamente giovato.

Mi pareva comunque strano come per i sette o otto anni precedenti il sistema a valle avesse elaborato ogni giorno centinaia di record inutili senza che sollevare il minimo problema.

In fase di test un file campione genenrato dal nuovo sistema doveva essere caricato dal sistema successivo. Il giorno del test ricevetti una telefonata ed il tecnico all’altro capo del filo mi disse che il test era fallito poichè alcuni record contenuti nel file non trovano riscontro nei dati di altre tabelle. Pronto ad affrontare una noiosissima sessione di debug mi accorsi che nel file prodotto non trovavo minimamente traccia dei record errati a cui si era riferito il tecnico.