LTS project (by lugge)

Specifiche tecniche e use cases

Queste specifiche non devono essere implementate tutte in una volta ma per gradi.

Hardware

A quanto pare tinycore linux richiede almeno 32Mb per funzionare mentre nxclient più di 32Mb:

  • Requisiti minimi per xterm su tinycore linux verificati il 7 maggio 2009: 32Mb RAM
  • Requisiti per nxclient su tinycore linux verificati il 6 maggio 2009:
    • OK — Pentium3 450MHz, 128Mb RAM, CDROM 40x
    • NO — Pentium3 450MHz, 64Mb RAM, CDROM 40x

Software

  1. Kernel 2.6 (supporta un parco hw più vasto) modulare (permette di aggiungere il supporto a nuove periferiche e funzionalità).
  2. Distribuzione con gestione pacchetti e/o modulare (più facile intervenire e quindi anche maggiore contributo della comunità).
  3. Il sistema deve auto avviarsi da Windows e permettere l'installazione anche in modalità windows (ad es. usando WUBI).
  4. Il sistema deve avere una modalità live dalla quale sono disponibili tutte le utilità necessarie per installarsi su partizione vfat, ntfs, ext2 (ad. es.: fdisk, parted, ntfs-utils, etc. etc.).
  5. Il sistema deve avere una modalità live dalla quale sono disponibili tutte le utilità necessarie per rimasterizzarsi (ad es.: mkisofs, cpio, cdrdao, etc. etc.)
  6. Il sistema è dotato di sistemi di sicurezza, anti-intrusione e connessione crittografata (ad. es.: iptables, ssh/dropbear)

Use Cases

  1. Se il sistema svolge un compito durante il quale l'utente non può interagire ma attendere allora il sistema deve fornire all'utente informazioni circa il compito che il sistema sta svolgendo.
  2. Ogni compito che fa attendere l'utente deve avere un indicatore di progresso o almeno un indicatore di "movimento" cioè l'utente non deve attendere più di 10 secondi per sapere se il sistema sta continuando a funzionare oppure si è bloccato.
  3. Se il sistema incontra un problema non bloccante deve avvisare l'utente con un errore che spieghi la natura dell'errore e possibilmente continuare in modalità manuale/provvisoria.
  4. Se il sistema incontra un problema bloccante deve avvisare l'utente del problema.

Esempi:

  1. Mancanza di DHCP: il sistema non deve bloccarsi ma avvisare l'utente che l'impostazione automatica della rete via DHCP è fallita e l'utente deve avere la possibilità di impostare manualmente IP address, netmask, gateway e DNS servers.
  2. Impossibilità di trovare il server freenx all'indirizzo di default e/o utilizzare le impostazioni/configurazioni di default: il sistema non deve bloccarsi ma avvisare l'utente che l'impostazione di default non è valida e permettere all'utente di modificare le configurazioni di default.

Network:

In questo caso i client della segreteria sono stati ricavati dall'estensione di quelli di un'aula quindi un approccio non approntato alla sicurezza nel disegnare la rete (domini con dati di diverso grado di confidenzialità debbono essere domini separati). Anche in questo caso il sistema deve garantire comunque un grado di separazione logica e sicurezza accettabile. Tralasciando la sicurezza e immaginando che siano due classi il sistema deve essere in grado di dirigersi verso il server appropriato (mediante configurazione dei client, configurazione dhcp, routing, etc. etc). Invece il laboratorio è il classico esempio nel quale tutti i servizi sono concentrati su un'unica macchina la quale fa anche da gateway con l'esterno.

network_schema.png

Sicurezza

  1. Sia in versione live-CDROM sia installato su periferica rimovibile deve avere password di root non nulla impostata.
  2. Se è installata su una periferica R/W allora la password di root deve poter essere cambiata.
  3. Nella versione live-CDROM la password di root deve essere "facilmente" modificabile rimasterizzando la ISO (cfr. requisito software n.5)
  4. Possibilità di alzare un firewall e se viene installata su una periferica R/W possibilità di avere un server ssh (cfr. requisito software n.6)

Optional

  1. Il sistema potrebbe avere un'interfaccia grafica per la configurazione dei parametri diversi dal default (cfr. use cases esempi n.1 e n.2)
  2. Il sistema potrebbe avere un sistema di compilazione e gli header necessari per compilare driver proprietari e/o driver sperimentali.
  3. Il sistema progettato secondo il requisito software n.2 potrebbe avere dei meta-pacchetti/moduli che si occupino di soddisfare macro-esigenze (ad.es.: compilare, rimasterizzare, sicurezza, installazione, etc. etc.)
  4. A parte il sistema di boot (bootloader) l'intero sistema live (non scrivibile) potrebbe essere contenuto in un unico file (suggerimento) ma facilmente questo punto può andare in conflitto con requisito software n.2, requisiti di sicurezza n.2 e n.3 mentre è in conflitto con il requisito software n.5 a meno di non integrare un sistema di ricompilazione del kernel per ottenere un unico binario kernel+cpio (il quale potrebbe essere comunque utile per installare driver proprietari e/o sperimentali).
  5. Il sistema se installato su una periferica R/W potrebbe fare upgrade pilotato da un server
  6. Il sistema se l'HW lo permette potrebbe fare il boot da rete (cfr. optional n.4)
  7. Il sistema potrebbe accettare come credenziali di login anche un token USB crittografico
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.