Re: Bug a la instal·lació de postgresql?
> >Malauradament limitar l'ús de su no és suficient per evitar que >un usuari amb root es pugui convertir fàcilment en un altre o >executar ordres en nom d'un altre: a banda del runuser i setpriv, >qualsevol llenguatge de programació prou genèric permetrà cridar >les funcions del sistema per fer-ho sense passar pel PAM. > Cert. >Se m'acut que la millor forma de què els alumnes tinguin root >però no interfereixin amb d'altres usuaris és que tinguin una >màquina virtual per cadascú. Segurament Àlex, però som de la filosofia de que facin servir sistemes reals i que els trenquin, com a sistema de capçalera, evidentment també fan servir VMs i Dockers. El problema realment és que es loguegin a una màquina on algun despistat ho hagi fet prèviament, ja que s'haurà muntat per NFS (kerberitzat) el directori d'aquest usuari despistat. Potser el que s'hauria de fer és permetre la exportació de segons quins directoris a segons quines IPs... Merci per les bones idees. Julio >Salut, >Alex > >-- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada > ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org > ⠈⠳⣄ > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: OT: Missatges descojunturats a Protonmail
Mira, ja que treus el tema, em recorda moltíssim a una cosa en què estava treballant abans de marxar de vacances. Tinc un programa que ha de descarregar-se els mails de una bústia de correu i guardar el cos en format text llegible... mira la de coses que vaig haver de fer per contemplar les múltiples formes de com els clients de correu t'envien els mails!!! de protonmail just vaig veure que a l'array que passa, el content-transfer-encoding era incorrecte! (no sé si això pot donar alguna pista del què passa). http://rafb.ath.cx/pastes/cPqFXS19.html Disculpeu que no sóc una gran programadora i encara he de donar-l'hi un parell de voltes al codi... però més o menys per aquí va la cosa xD - Blackhold http://blackhold.nusepas.com @blackhold_ ~> cal lluitar contra el fort per deixar de ser febles, i contra nosaltres mateixos quan siguem forts (Xirinacs) <°((( >< Missatge de Joan del dia ds., 2 d’oct. 2021 a les 12:15: > > Hola Robert, > > Veig que uses protonmail. Et puc preguntar si tens problemes de > desconfiguració del text en els missatges que et responen o > reenvien amb text citat? Tinc una amiga a la que li passa amb els meus > missatges, i imagino que hi ha d'haver alguna opció de configuració > perquè entengui bé els missatges de text. > > I, més en general, amb la merda de missatges de mail en format html, > més els sistemes de mostrar-los de fills de cada Gmail o Outllok, etc > (tot el contrari de la simple i pura estandarització), sembla mentida > que els que usem el format text, que mira que més senzill no pot ser, > tinguem problemes :-) > > -- > Joan Cervan i Andreu > http://personal.calbasi.net > > "El meu paper no és transformar el món ni l'home sinó, potser, el de > ser útil, des del meu lloc, als pocs valors sense els quals un món no > val la pena viure'l" A. Camus > > i pels que teniu fe: > "Déu no és la Veritat, la Veritat és Déu" > Gandhi > > "Donar exemple no és la principal manera de influir sobre els altres; > es la única manera" Albert Einstein > > “Lluitarem contra el fort mentre siguem febles i contra nosaltres > mateixos quan siguem forts” Lluís Maria Xirinacs > > > El Wed, 18 Aug 2021 16:53:18 + > robert marsellés va escriure: > > > Hola, > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, August 18th, 2021 at 18:12, Narcis Garcia > > wrote: > > > > > El 17/8/21 a les 14:11, Eduard Selma ha escrit: > > > > > > > - L'instal·lador Calamares (omnipresent) naturalment, no permet > > > > fer > > > > > > > > entrades de particions "a mida" (com /data, /back, etc) tal > > > > com feia > > > > > > > > l'instal·lador antic Debian; només les estàndard (/boot, > > > > /var, /home, > > > > > > > > etc.) Cal fer blkid i entrar-ho manualment un cop instal·lat. > > > > cap > > > > > > > > problema, però. > > > > > > Em sembla que amb l'arrencada de DebianInstaller (sense escriptori > > > > > > gràfic ni Calamares) segueix podent-se fer de tot amb les > > > particions, > > > > > > LVM, RAID, LUKS... > > > > > > > Pel que diu la pàgina web a la secció "Want to give it a try? [1], > > "Calamares" està únicament a la versió "live": "The live image > > includes the Calamares independent installer as well as the standard > > Debian Installer." Entenc que es deu poder triar quin instal·lador es > > vol o s'utilitza una còpia de Bullseye "normal" (no-live) que tindrà > > únicament l'instal·lador estàndar "Debian Installer". A les "release > > notes" [2], es diu que l'instal·lador oficial és el "Debian > > Installer" que està als CDs, DVDs, ... [2], no diu rés de la versió > > "live". > > > > Per altra banda, al mateix document es recomana passar a Bullseye a > > partir d'un sistema el més "net" (entenc estàndard) possible de > > paquets. És a dir, s'elimina tot allò que no és estàndard > > (guardant-ne la configuració) i, un cop finalitzat el procés, després > > es torna a instal·lar el que vulgui [3]. > > > > Salut i peles, > > > > robert > > > > > > [1] https://www.debian.org/News/2021/20210814 > > [2] > > https://www.debian.org/releases/bullseye/amd64/release-notes/ch-installing.es.html > > [3] > > https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.es.html#system-status > > > > > > -- > Joan Cervan i Andreu > http://personal.calbasi.net > > "El meu paper no és transformar el món ni l'home sinó, potser, el de > ser útil, des del meu lloc, als pocs valors sense els quals un món no > val la pena viure'l" A. Camus > > i pels que teniu fe: > "Déu no és la Veritat, la Veritat és Déu" > Gandhi > > "Donar exemple no és la principal manera de influir sobre els altres; > es la única manera" Albert Einstein > > “Lluitarem contra el fort mentre siguem febles i contra nosaltres > mateixos quan siguem forts” Lluís Maria Xirinacs >
Re: Bug a la instal·lació de postgresql?
Hola, Julio > Quan un d'aquests despistats del grup B, es logueja i s'oblida > de fer kdestroy, el tiquet de kerberos roman durant unes hores > a l'ordinador i en aquest moment, qualsevol usuari amb el compte > local de root pot fer un `su -l usuari_despistat_del_grup_B` Això és el que sospitava, gràcies per explicar-ho amb detall. Malauradament limitar l'ús de su no és suficient per evitar que un usuari amb root es pugui convertir fàcilment en un altre o executar ordres en nom d'un altre: a banda del runuser i setpriv, qualsevol llenguatge de programació prou genèric permetrà cridar les funcions del sistema per fer-ho sense passar pel PAM. Se m'acut que la millor forma de què els alumnes tinguin root però no interfereixin amb d'altres usuaris és que tinguin una màquina virtual per cadascú. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: pregunta sobre el nucli Linux
> El problema és quan el sistema es queda sense memòria i comença a fer > servir swap el funcionament es s'alenteix tant que el sistema queda > inutilitzable, fins al punt que no és possible ni tan sols matar el > procés manualment. Suposo que si t'esperes suficientment l'oom-killer > l'acabaria matant, però jo mai he tingut tanta paciència. Personalment > he optat per no tenir swap, per evitar aquestes situacions. > > Salutacions. > > Tot i que se m'escapa algun concepte trobo interessantíssim el que entenc. Desviant-me una mica del tema i entenen que no hi ha una resposta universal, com bé diu Eloy ni per a un mateix usuari, em recomaneu per a ordinadors d'alumnes de cicles no posar swap? A banda de que la swap vagi bé per a la hibernació, he pensat que el dia que decideixi no tenir-la trobaré un programa antic i important de Murphy amb un if que m'enviarà a l'infern si no troba la swap. Però potser són paranoies. Vagi bé Julio -- __ - El 2003 el català era la llengua habitual del 46 % dels catalans. Al 2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà. - El 3 de novembre representa el moment de l'any en el que les dones deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a eliminar aquesta data. - L’administració pública cada any es gasta milions d’euros en llicències de programari privatiu. Utilitzant programari lliure estalviem costos i incentivem l’economia local. *La neutralitat davant les desigualtats acaba accentuant-les.*
Re: Debian 11 estable en poques hores
Missatge de Ernest Adrogué del dia dg., 3 d’oct. 2021 a les 11:02: > > 2021-10- 2, 15:47 (+0200); Aleix Vidal i Gaya escriu: > > Fixa't en els parèntesis: "quan s'apliqui". Diria que la solució de > > compromís encara no s'ha aplicat, per tant entenc que estàs valorant una > > situació que no es correspon a la que deia en Joan. > > Estic valorant la solució proposada, independentment de si s'ha aplicat > o no. Aquesta solució no soluciona el problema, perquè el problema > també afecta a altres programes, com ja havia apuntat anteriorment, a > banda de la utilitat 'ls'. La estratègia d'anar adaptant un a un tots > els programes que puguin estar afectats no és realista, tenint en compte > el que hem vist: que després de més de quatre anys arrossegant aquesta > situació encara no n'hem aconseguit adaptar ni un. A més, sobre qui > recaurà el cost de fer totes aquestes adaptacions? > Torno a discrepar en el fet que fa 4 anys que arrosseguem el problema. No és ben be cert. La cadena de traducció de «ls» no s'estava aplicant (per això en fer «ls -al» usava el format de data americà, mesos anys). Ara sí que s'aplica la cadena de traducció que adapta el format, i es va prendre cura perquè els mesos quedessin en columnes. El problema és que Debian ha canviat la versió de core-utils sense passar pel translation-project, i per això la solució que tenim ara no és la que es volia. Quan parlava de situació de compromís em referia al fet que la solució ideal no existeix, i la que tindrem serà un equilibri perquè el format de data a «ls» quedi "prou bé". Sobre la resta de programes, No sé si és realista apedaçar programes 1 per 1. El que sí que tinc clar és que a escriptori els programes es veuen bé. Confio que no proposeu d'usar els símbols perquè a terminal es veu milor, penseu que afecta tot el sistema. També a escriptori. De moment, fa uns dies vaig obrir un bug a dmesg [1], i ja han afegit la capacitat de definir el format de data via la traducció. Ara serà feina del traductor de dmesg decidir quin format de data vol. A systemd [2] no he obtingut, de moment, la mateixa sort. Sembla que no volen permetre la i18n del format de data predeterminat. Si algú vol aportar arguments al tiquet, és més que benvingut. Així, de memòria, aplicacions gràfiques que mostrin els mesos abreujats se m'acuden "l'escriptori" d'Android i l'aplicació Google Calendar. Encara no sé per què estic en aquest embolic. Per Nadal passat, vaig resseguir el tema de l'ordre incorrecte de data de «ls» i vaig voler compartir-ho aquí, perquè em pensava que us molestava tant com a mi. Per la meva part, d'aquest tema ja he dit tots els arguments que tinc. No sóc Debian developer ni tinc accions als mesos abreujats amb preposició, el que faré és, siguin quines siguin les dades del locale català, intentar que els programes apareguin el millor possible. Salutacions, Joan Montané [1] https://github.com/karelzak/util-linux/issues/1451 [2] https://github.com/systemd/systemd/issues/20785
Re: pregunta sobre el nucli Linux
2021-10- 3, 03:12 (+0200); Jordi Miguel escriu: > Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, > segons el que ens expliquen probablement hauria d'haver passat, però > també és possible que no s'hagués exhaurit tota la memòria sinó que > s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha > arribat a cridar el oom-killer. En aquest escenari el Firefox > intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo > que ha decidit l'usuari de la màquina. El problema és quan el sistema es queda sense memòria i comença a fer servir swap el funcionament es s'alenteix tant que el sistema queda inutilitzable, fins al punt que no és possible ni tan sols matar el procés manualment. Suposo que si t'esperes suficientment l'oom-killer l'acabaria matant, però jo mai he tingut tanta paciència. Personalment he optat per no tenir swap, per evitar aquestes situacions. Salutacions.
Re: Debian 11 estable en poques hores
2021-10- 2, 21:05 (+0200); Josep Lladonosa escriu: > i he descobert que, a més de les abreviacions de mes, n'indiquen símbols de > dues lletres: > > GN, FB, MÇ, AB, MG, JN, JL, AG, ST, OC, NV, DS > > i de llargada fixa! Potser es podrien usar aquestos? Es podrien usar símbols de 2 lletres. Personalment, crec que és millor utilitzar 3 caràcters, perquè el local per defecte "C" utilitza 3 caràcters (tant pels mesos, com pels dies). Si mantenim la mateixa llargada que el local "C", és menys probable que després els programes no funcionin com s'espera que funcionin i s'hagin d'adaptar, cosa que comporta un cost. Però estic d'acord que haurien de ser símbols, i no abreviacions. El document que enllaces defineix un símbol com "la representació convencional d’un concepte (una paraula, un sintagma o un valor), normalment mitjançant un element gràfic" i diu que "no porten mai punt abreviatiu". Per exemple - 1.000.000 d'eur. - 1.000.000 EUR el primer cas és una abreviació, i el segon un símbol. En un llistat de directori, i altres situacions similars, opino que és més convenient utilitzar símbols que abreviacions. Salutacions.
Re: Debian 11 estable en poques hores
2021-10- 2, 20:39 (+0200); Eduard Selma escriu: > + 1 altre a favor de les 3 lletres (GEN, FEB, MAR, ABR, MAI, JUN, JUL, AGO, > SET, OCT, NOV i DES). Com als datadors de goma. Tan difícil és? Difícil no és. L'únic que fa falta és la voluntat de fer-ho per part de les persones que s'encarreguen de mantenir el local. Però són les mateixes persones que van canviar les cadenes originals de tres lletres per la versió abreviada actual. Salutacions
Re: Debian 11 estable en poques hores
2021-10- 2, 15:47 (+0200); Aleix Vidal i Gaya escriu: > Fixa't en els parèntesis: "quan s'apliqui". Diria que la solució de > compromís encara no s'ha aplicat, per tant entenc que estàs valorant una > situació que no es correspon a la que deia en Joan. Estic valorant la solució proposada, independentment de si s'ha aplicat o no. Aquesta solució no soluciona el problema, perquè el problema també afecta a altres programes, com ja havia apuntat anteriorment, a banda de la utilitat 'ls'. La estratègia d'anar adaptant un a un tots els programes que puguin estar afectats no és realista, tenint en compte el que hem vist: que després de més de quatre anys arrossegant aquesta situació encara no n'hem aconseguit adaptar ni un. A més, sobre qui recaurà el cost de fer totes aquestes adaptacions? Salutacions.
Re: pregunta sobre el nucli Linux
El 3/10/21 a les 3:12, Jordi Miguel ha escrit: [...] Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, segons el que ens expliquen probablement hauria d'haver passat, però també és possible que no s'hagués exhaurit tota la memòria sinó que s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha arribat a cridar el oom-killer. En aquest escenari el Firefox intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo que ha decidit l'usuari de la màquina. Per això suggeria desactivar la swap, per evitar el problema del bolcat a disc: el oom-killer no saltarà fins que estigui també tota la swap plena, i si està sobre un disc magnètic doncs trigarà una bona estona a emplenar-la, i mentrestant el sistema no serà responsiu. Sobre els límits per procés en sistemes compartits, com bé s'ha dit és configurable però alhora no hi ha una configuració que serveixi per a tothom. Jo mateix, quan faig servir l'ordinador durant el dia sí que voldria evitar que un únic procés es desmadrés i em tirés avall tota la màquina, però si el deixo funcionant durant la nit amb alguna feina computacionalment costosa, que agafi tots els recursos que pugui, si la resta s'alenteix ben poc que em preocupa mentre dormo... és que ni una "solució universal" pot ser vàlida ni tan sols per al mateix usuari segons l'hora del dia.
