Il rila­scio di Leopard com­prende anche la nuova ver­sione di Xgrid che, com’è facile imma­gi­nare, si è evo­luta sen­si­bil­mente rispetto alla pre­ce­dente e comin­cia anche ad essere uti­liz­zata per altri pro­dotti di Apple, come Podcast Producer, su cui un giorno dovremo ritor­nare.  Tuttavia la cosa vera­mente inte­res­sante di Xgrid 2 è Scoreboard.

Lo scopo di Scoreboard è sem­plice: for­nire un sistema per distri­buire in modo selet­tivo i job di Xgrid. L’architettura per rag­giun­gere que­sto scopo è un po’ più com­plessa da spiegare.

Prima di tutto serve un qual­che tipo di cri­te­rio per sele­zio­nare i nodi di desti­na­zione dei job. In Xgrid que­sto cri­te­rio è un sem­plice script di shell, che Scoreboard usa per cal­co­lare il ran­king di ogni nodo. Questo script, nella ter­mi­no­lo­gia di Xgrid, è un Agent Ranking Tool (ART).

Alla sot­to­mis­sione di un job, for­nendo un ART, il con­trol­ler lo ese­guirà su ogni nodo e, in base al risul­tato, deci­derà a quali nodi far ese­guire il job e con quale prio­rità. Il risul­tato è un sem­plice valore nume­rico e se è uguale a zero il nodo viene scar­tato. Sta ovvia­mente a chi scrive l’ART il com­pito di pro­durre dei numeri sensati.

Gli ART pos­sono essere com­bi­nati pro­du­cendo un risul­tato com­ples­sivo che è il pro­dotto dei sin­goli risul­tati. Usando la mol­ti­pli­ca­zione diventa banale pre­ser­vare la pos­si­bi­lità di esclu­sione dei nodi: basta che uno degli ART dia come risul­tato zero.  Ma non è finita qui! È pos­si­bile anche fil­trare i nodi in base al valore del risul­tato: ad es. sele­zio­nando i nodi con un pun­teg­gio supe­riore a 1.000.

Trovo quest’idea molto inte­res­sante e anzi credo sia uti­liz­za­bile anche in altri sce­nari. Ad es. potremmo sfrut­tare l’infrastruttura che Xgrid mette a dispo­si­zione per distri­buire aggior­na­menti, con­fi­gu­ra­zioni in maniera selet­tiva e robu­sta: basta legare il pun­teg­gio dell’ART alla pre­senza o meno dell’aggiornamento che stiamo distri­buendo, evi­tando quindi la riap­pli­ca­zione dell’aggiornamento nel caso in cui doves­simo ripe­tere la procedura.

Links utili:

• “Xgrid Leopard: the good, the bad, the ugly, and the new stuff”;
• “Xgrid Leopard: Scoreboard rules!”.

Qualche giorno accen­navo al fatto che con Mac OS X 10.5 è pos­si­bile usare path_helper per con­fi­gu­rare il path. #

Tuttavia, almeno per me, la sua uti­lità è rela­tiva dato che i path ausi­liari ven­gono aggiunti in coda agli altri. Questo vuol dire che se voglio usare una ver­sione custom di emacs devo usare comun­que i file di con­fi­gu­ra­zione clas­sici (.basrc & company).

Il search path è l’insieme di direc­to­ries entro cui cer­care dei file, tipi­ca­mente degli ese­gui­bili ed è una delle impo­sta­zioni che, se si usa il ter­mi­nale in modo con­ti­nuato, tende ad essere quasi sem­pre adat­tata al pro­prio ambiente di lavoro.

Di solito la per­so­na­liz­za­zione viene fatta attra­verso la modi­fica di file di con­fi­gu­ra­zione della shell come .bashrc ma con Leopard esi­ste un’altra pos­si­bi­lità ed è quella di usare /etc/paths.d e /etc/manpaths.d.

In que­ste direc­to­ries è pos­si­bile aggiun­gere dei file che elen­cano ulte­riori per­corsi di ricerca. Ad es. se voglio aggiun­gere gli ese­gui­bili di mysql non fac­cio altro che aggiun­gere il file /etc/paths.d/mysql, al cui interno elen­cherò dove cer­care gli ese­gui­bili. #

Questo sistema ha il van­tag­gio di essere più con­si­stente fra le varie shell e con­di­vi­si­bile fra più utenti. Tuttavia vor­rei capire quali pos­sono essere le impli­ca­zioni nell’ordine di ricerca e nell’esecuzione di comandi via cron.

Altre info: path_helper(8).

Ho aggiunto un arti­colo sull’LVM (chia­mia­molo così…). Prego usare il form dei commenti ;-)

Il rila­scio della ver­sione 10.5.1 di Mac OS X con­tiene alcuni ritoc­chi al firewall. In par­ti­co­lare, è pos­si­bile adesso è pos­si­bile bloc­care espli­ci­ta­mente anche i pro­cessi che girano a nome di root e le modi­fi­che agli accessi, per pro­cessi gestiti da laun­chd, sono immediate.

So che par­lare di stampa può sem­brare molto retro ma vi assi­curo che qual­cuno, là fuori, ne ha ancora biso­gno; e magari ha anche biso­gno di tener trac­cia di chi stampa cosa e quanto; e magari lo deve fare in un ambiente misto.Insomma, un mezzo incubo.

Fino ad oggi, sotto Mac OS X era pos­si­bile auten­ti­carsi per la stampa in IPP usando un URL del tipo ipp://account:password@server/printer e quindi espo­nendo infor­ma­zioni poten­zial­mente sensibili.Leopard irro­bu­sti­sce il sup­porto all’IPP auten­ti­cato, anche se ancora con qual­che difetto, per­met­tendo un uso meno fra­gile delle credenziali.

Per aggi­rare i pro­blemi di usa­bi­lità seguite que­ste istru­zioni, su Mac OS X Hints: “10.5: Set up authen­ti­ca­ted prin­ting via IPP”.

Come ho già avuto occa­sione di dire, Time Machine è forse la novità più utile di Leopard per il grado di sem­pli­fi­ca­zione che intro­duce in un com­pito tedioso come il bac­kup. Il pro­cesso per atti­vare Time Machine è sem­plice: pra­ti­ca­mente basta aprire le pre­fe­renze e sele­zio­nare il disco di desti­na­zione del bac­kup; quando non è già stato fatto dopo l’installazione di Mac OS X 10.5.

Da quel momento in poi, Time Machine terrà un bac­kup ogni ora, nelle prime 24 ore; un bac­kup gior­na­liero, nel primo mese; un bac­kup set­ti­ma­nale fino a quando il disco non è pieno. Se non ci basta e vogliamo fare un bac­kup seduta stante, basta atti­vare il menu con­te­stuale dal dock:

Come ho già scritto pre­ce­den­te­mente, ci sono state diverse impor­tanti modi­fi­che a livello di Kerberos nel Mac OS X 10.5. Una di que­ste, che non mi sem­bra par­ti­co­lar­mente bril­lante, per­mette di evi­tare la richie­sta della pas­sword quando scade il tic­ket, per­met­tendo alle appli­ca­zioni di rin­no­varlo senza inter­vento dell’utente.

È pos­si­bile evi­tare disa­bi­li­tare que­sta “fea­ture” tra­mite defaults:

defaults write edu.mit.Kerberos.KerberosAgent \
  SavePasswordDisabled -bool YES

Per chi ha seguito l’evoluzione del Mac OS X in tutti que­sti anni sa che una delle cose ere­di­tate da NeXT è il NetInfo, un data­base delle con­fi­gu­ra­zioni usate dal sistema ope­ra­tivo. L’idea di base era quella di eli­mi­nare tutta la ple­tora di file di testo (di solito in /etc) usati negli ambienti UNIX.

Questo suc­ce­deva dieci anni e i file di testo sono ancora lì, vivi e vegeti, men­tre con la ver­sione 10.5 il glo­rioso ma non molto amato NetInfo viene man­dato in pen­sione. A livello di dae­mons rimane DirectoryService che ingloba lookupd e memberd, men­tre i dati sono ora con­ser­vati in una serie di file XML sotto /var/db/dslocal/nodes/Default/. Le infor­ma­zioni sono esat­ta­mente le stesse di prima – ed è sem­pre pos­si­bile uti­liz­zare anche i file UNIX tra­di­zio­nali – ma ora, essendo modi­fi­ca­bili con un sem­plice edi­tor di testo, molte cose diven­tano più sem­plici e più in linea con la filo­so­fia UNIX.

Altre info: “Leopard Server Part 2 — Local Directory Services”.

Ecco il clas­sico post che può sal­varvi la gior­nata: come instal­lare Leopard da CLI su una mac­china avviata in tar­get mode e con un’architettura diversa.

Può anche darsi che valga per ver­sioni pre­ce­denti di sistema operativo.