Førstesiden Bli medlem Kontakt Informasjon Medlemsfordeler Utvalg Kalender NUUG/HIO prisen Dokumenter Innmelding Ressurser Mailinglister Wiki Linker Om de aktive Kart NUUG i media Planet NUUG webmaster@nuug.no
Powered by Planet! Last updated: August 05, 2021 05:00 PM

Planet NUUG

August 04, 2021

Petter Reinholdtsen

Mechanic's words in five languages, English, Norwegian and Northern Sámi editions

Almost thirty years ago, some forward looking teachers at Samisk videregående skole og reindriftsskole teaching metal work and Northern Sámi, decided to create a list of words used in Northern Sámi metal work. After almost ten years this resulted in a dictionary database, published as the book "Mekanihkkársánit : Mekanikerord = Mekaanisen alan sanasto = Mechanic's words" in 1999. The story of this work is available from the pen of Svein Lund, one of the leading actors behind this effort. They even got the dictionary approved by the Sámi Language Council as the recommended metal work words to use.

Fast forward twenty years, I came across this work when I recently became interested in metal work, and started watching educational and funny videos on the topic, like the ones from mrpete222 and This Old Tony. But they all talk English, but I wanted to know what the tools and techniques they used were called in Norwegian. Trying to track down a good dictionary from English to Norwegian, after much searching, I came across the database of words created almost thirty years ago, with translations into English, Norwegian, Northern Sámi, Swedish and Finnish. This gave me a lot of the Norwegian phrases I had been looking for. To make it easier for the next person trying to track down a good Norwegian dictionary for the metal worker, and because I knew the person behind the database from my Skolelinux / Debian Edu days, I decided to ask if the database could be released to the public without any usage limitations, in other words as a Creative Commons licensed data set. And happily, after consulting with the Sámi Parliament of Norway, the database is now available with the Creative Commons Attribution 4.0 International license from my gitlab repository.

The dictionary entries look slightly different, depending on the language in focus. This is the same entry in the different editions.

English

lathe

dreiebenk (nb) várve, várvenbeaŋka, jorahanbeaŋka, vátnanbeaŋka (se) svarv (sv) sorvi (fi)

Norwegian

dreiebenk

lathe (en) várve, várvenbeaŋka, jorahanbeaŋka, vátnanbeaŋka (se) svarv (sv) sorvi (fi)

(nb): sponskjærande bearbeidingsmaskin der ein med skjæreverktøy lausgjør spon frå eit roterande arbetsstykke

Northern Sámi

várve, várvenbeaŋka, jorahanbeaŋka, vátnanbeaŋka

dreiebenk (nb) lathe (en) svarv (sv) sorvi (fi)

(se): mašiidna mainna čuohppá vuolahasaid jorri bargoávdnasis

(nb): sponskjærande bearbeidingsmaskin der ein med skjæreverktøy lausgjør spon frå eit roterande arbetsstykke

The database included term description in both Norwegian and Northern Sámi, but not English. Because of this, the Northern Sámi edition include both descriptions, the Norwegian edition include the Norwegian description and the English edition lack a descripiton.

Once the database was available without any usage restrictions, and armed with my experience in publishing books, I decided to publish a Norwegian/English dictionary as a book using the database, to make the data set available also on paper and as an ebook. Further into the project, it occurred to me that I could just as easily make an English dictionary, and talking to Svein and concluding that it was within reach, I decided to make a Northern Sámi dictionary too.

Thus I suddenly find myself publishing a Northern Sámi dictionary, even though I do not understand the language myself. I hope it will be well received, and can help revive the impressive work done almost thirty years ago to document the vocabulary of metal workers. If I get some help, I might even extend it with some of the words I find missing, like collet, rotary broach, carbide, knurler, arbor press and others. But the first edition build from a lightly edited version of the original database, with no new entries added. If you would like to check it out, visit my list of published books and consider buying a paper or ebook copy from lulu.com. The paper edition is only available in hardcover to increase its durability in the workshop.

I am very happy to report that in the process, and thanks to help from both Svein Lund and Børre Gaup who understand the language, the docbook tools I use to create books, dblatex and docbook-xsl, now include support for Northern Sámi. Before I started, these lacked the needed locale settings for this language, but now the patches are included upstream.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

August 04, 2021 01:30 PM

August 03, 2021

Peter Hansteen (That Grumpy BSD Guy)

Badness, Enumerated by Robots

A condensed summary of the blacklist data generated from traffic hitting bsdly.net and cooperating sites.

After my runbsd.info entry (previously bsdjobs.com) was posted, there has been an uptick in interest about the security related data generated at the bsdly.net site. I have written quite extensively about these issues earlier so I'll keep this piece short. If you want to go deeper, the field note-like articles I reference and links therein will offer some further insights.

There are three separate sets of downloadable data, all automatically generated and with only very occasional manual intervention.


Known spam sources during the last 24 hours

This is the list directly referenced in the runbsd.info piece.

This is a greytrapping based list, where the conditions for inclusion are simple: Attempts at delivery to known-bad addresses (download link here) in domains we handle mail for have happened within the last 24 hours.

In addition there will occasionally be some addresses added by cron jobs I run that pick the IP addresses of hosts that sent mail that made it through greylisting performed by our spamd(8) but did not pass the subsequent spamassassin or clamav treatment. The bsdly.net system is part of the bgp-spamd cooperation.

The traplist has a home page and at one point was furnished with a set of guidelines.

A partial history (the log starts 2017-05-20) of when spamtraps were added and from which sources can be found in this log (or at this alternate location). Read on for a bit of information on the alternate sources.

Note: The list is generated at ten past every full hour by a script that uses essentially the one-liner

    spamdb | grep TRAPPED | awk -F\| '{print $2}' >bsdly.net.traplist

to generate the body of the list.

Misc other bots: SSH Password bruteforcing, malicious web activity, POP3 Password Bruteforcing.

The bruteforcers list is really a combination of several things, delivered as one file but with minimal scripting ability you should be able to dig out the distinct elements, described in this piece.

The (usually) largest chunk is a list of hosts that hit the rate limit for SSH connections described in the article or that was caught trying to log on as a non-existent user or other undesirable activity aimed at my sshd(8) service. Some as yet unpublished scriptery helps me feed the miscreants that the automatic processes do not catch into the table after a manual quality check. For a more thorough treatment of ssh bruteforcers, see the The Hail Mary Cloud and the Lessons Learned overview article which links to several other articles in the sequence.

The second part is a list of IP addresses that tried to access our web service in undesirable ways, including trying for specific URLs or files that will never be found at any world-facing part of our site.

After years of advocating short lifetimes (typically 24 hours) for blacklist entries only to see my logs fill up with attempts made at slightly slower speeds, I set the lifetime for entries in this data set to 28 days (since expanded to 2419200 seconds, or if you will, six weeks). The background including some war stories of monitoring SSH password groping can be found in this piece, while the more recent piece here covers some of the weeding out bad web activity.

The POP3 gropers list comes in two variations. Again lists of IP addresses caught trying to access a service, most of those accesses are to non-existent user names with an almost perfect overlap with the spamtraps list, local-part only (the part before the @ sign).

The big list is a complete corpus of IP addresses that have tried these kinds of accesses since I started recording and trapping them (see this piece for some early experience and this one for the start of the big collection).

There is also a smaller set, produced from the longterm table described in this piece. For much the same reason I did not stick to 24-hour expiry for the SSH list, this one has six-week expiry. With some minimal scriptery I run by hand one or two times per day, any invalid POP3 accesses to valid accounts get their IP adresses added to the longterm table and the exported list.

Note: The lists generated by table exports are generated by variations of pfctl's show table subcommand. At ruleset reload such as reboots after a sysupgrade, the tables are re-initialized from these same exported files.

If you're wondering about the title, the term "enumerating badness" stems from Marcus Ranum's classic piece The Six Dumbest Ideas in Computer Security. Please do read that one.

Here are a few other references other than those referenced in the paragraphs above that you might find useful:

The Book of PF, 3rd edition
Hey, spammer! Here's a list for you! which contains the announcement of the bsdly.net traplist.
Effective Spam and Malware Countermeasures, a more complete treatment of those keywords

If you're interested in further information on any of this, the most useful contact information is in the comment blocks in the exported lists.

Update 2020-07-29: I added a direct link to the complete list of spamtraps, since the web page seemed a bit crowded to at least one visitor. Direct link again here for your convenience.

Update 2021-01-15: Note that at some point after the article was written I cranked up expiry for the bruteforce tables to six weeks (sorry, I forgot to note the exact date).

Update 2021-03-11: In light of recent Microsoft Exchange exploits it might interest some that any request to bsdly.net for "GET /owa/" lands the source in the webtrash table, exported as part of the bruteforcers list.

Update 2021-08-03: Added notes about how the lists are generated and table maintenance.

by Peter N. M. Hansteen (noreply@blogger.com) atAugust 03, 2021 11:40 AM

July 31, 2021

Petter Reinholdtsen

Hva mener partiene om vern av privatsfæren og sporing av befolkningen?

Årsaken til at vi på dugnad oversatte og ga ut boken «Hvordan knuse overvåkningskapitalismen» av Cory Doctorow er at vi mener den tar opp et viktig tema og bør leses av så mange som mulig. Temaene boken tok opp, og det kommende valget, inspirerte nylig oss som sto bak utgivelsen til å sende inn spørsmål til partiene sammen med et eksemplar av boken. Vi er veldig spent på hva de ulike partiene kommer til å svare. Spørsmålene er sendt til samtlige partier som er representert på stortinget, men vi tar naturligvis imot svar også fra andre partier. Det er for mange partier i Norge til å ta kostnaden med å sende til alle, så vi begrenset oss til de som er representert på Stortinget.

Her er brevet som ble postlagt til partiene tidligere i uka:

OM DIGITALE PLATTFORMER OG STORDATA – MED SEKS KONKRETE FORSLAG

Det er en økende grad av mistillit til digitale plattformer fordi den delen av vårt sam­funn mangler helt grunnleggende demokratiske kjøreregler. Begrepet «privat­livets fred» er i ferd med å dø som et resultat av digitaliseringen. Som brukere har vi ikke kontroll over våre personlige data og er helt frarøvet et digitalt privatliv. Dette dels fordi samfunnet rundt oss samler inn data om oss og våre bevegelser, samtidig som noen globale aktører samler data om alle. Denne utviklingen er preget av kaos og manglende regulering.

Disse digitale utfordringene kan være vanskelig å formulere enkelt inn i et parti­program og enda vanskeligere å dekke helhetlig. Vi har derfor valgt å sette søkelys på noen utvalgte områder som vi mener partiene burde ta klare standpunkt til.

Personvern

I følge tekologirådets direktør Tore Tennøe kan det, når offentlige virksomheter som Sivil­ombuds­mannen, Likestillings- og diskrimineringsombudet og Medietilsynet alle deler brukerdata med Google-tjenestene Analytics, remarketing audiences og an­nonsebørsen Doubleclick, fort komme i veien for samfunnsoppdraget deres. Uttalelsen kommer i forbindelse med en rapport fra Teknologi­rådet som viser at en stor andel av offentlige virksomheter deler personinformasjon om de som besøker virksomhetenes nettsider med kommersielle aktører.1 Stortinget er i følge rapporten en av disse.

I forbindelse med Covid 19 har bruken av videokonferanseløsninger økt dramatisk. Løsninger som Microsoft Teams og Zoom har åndsverksbruksvilkår som hindrer bruk­erne å undersøke sikker­heten i systemene ved å forby omvent utvikling. Fri programvareløsninger som Jitsi og Big Blue Button, har ikke slike begrensinger, kan tas i bruk uavhengig av utenlandske leverandører og gir brukerne slik bedre sikkerhet.

Facebook er ikke offentlig digital infrastruktur

Leder for det tyske datatilsynet BfDI, Ulrich Kelber, anbefalte sterkt i et brev til tyske myndigheter nylig at de stengte sine Facebook-sider og avslutter kobling mellom egne sider og Facebook.2 3 Bakgrunnen er at bruken av Facebook ikke er i tråd med EU- og EØS-lovgivingen om vern av privatsfæren, personvernforordningen GDPR.

Massiv overvåkning av digitale brukere

De store globale plattformene samler inn data om oss alle gjennom sine tjenester. Data akkumuleres og videreselges, med påstand om at informasjonen er anonymisert. Data om geoposisjon er også noe teleselskapene samler inn om alle brukere, selv de som har helt enkle mobiltelefoner.4 5 EUs personvernmyndighet, har i sitt arbeid med GDPR, presisert at anonymisering ikke må forveksles med pseudoanonymisering6, som fortsatt er underlagt personvernlovgivningen, og at mobilers geografiske plassering (lokasjonsdata) ikke kan anonymiseres.

En av mange saker som dokumenterer disse utfordringene er NRK som kjøpte «anonymiserte» lokasjonsdata7, og ved hjelp av enkel analyse kunne identifi­sere enkeltindivider.

Grunnskolen i Norge har i stor grad tatt i bruk Internett-baserte løsninger, og de fleste av disse samler inn personopplysninger om elever og lærere som lagres på datamaskiner utenfor både Norge og EU. I tillegg til å rapportere bruk til for eksempel Google Ana­lytics, så bruker mange av tjenestene datamaskiner eid av Amazon og Microsoft. Dette fører totalt til en massiv spredning og innsamling av personopplysninger utenfor skolene om elever i norske skoler.

Spørsmålene vi stiller til de politiske partiene er som følger:

  1. Er dere enige med det tyske datatilsynet om at offentlige instanser ikke bør dele informasjon om sine ansatte og lesere med selskaper i strid med GDPR, og derfor bør stenge sine Facebook-sider?
  2. Er dere enig med Teknologirådet i at offentlig sektor bør velge løsninger og verk­tøy som følger personvernprinsippene, og samler inn minimalt med data til helt spesifikke formål?
  3. Bør det være mulig å bevege seg i Norge med mobiltelefon uten at ens posisjon sam­les inn og selges videre av teleselskapene?
  4. Bør det offentlige velge videoløsninger som sikrer brukernes rettigheter når det gjelder sikkerhet, personvern og innsyn?
  5. Hva tenker deres parti man burde gjøre for å forhindre massiv overvåkning av bru­kere i Norge?
  6. Er deling av elevenes personopplysninger til aktører utenfor skolen, potensielt i strid med GDPR, en akseptabel kostnad for å forenkle kommunenes drift av skoler?8

Om det er behov for ytterligere avklaringer og bakgrunnsinformasjon, ta gjerne kontakt! Epostadressen vår er til Petter Reinholdtsen: pere-valg2021 (at) hungry.com. Spørsmålene samt svarene vi mottar vil bli publisert.

Den internasjonale bakgrunnen

Internasjonalt pågår det en stadig bredere faglig og politisk drøfting av de viktige bakenforliggende problem­stillingene. Ett eksempel er vedlagte bok der dr. Cory nettopp drøfter definerende problem­stillinger fom følger den nasjonale og internasjonale utviklingen av «stordata». Boken peker også på helt konkrete innsatsområder.

Når for eksempel Rand Worldwide viser til at Facebook «radikaliseres», og når Facebook i sin tur sprer feilinformasjon om coronaviruset med en forklaring om sine algoritmer, blir det implisitte bud­skapet at maskinlæring og overvåkning kan endre vår oppfattelse av hva som er sant. Begrepet «overvåkingskapitalisme» er nå blitt det vanlig brukte ordet for å kjennetegne både beskivelsene og debatten på dette vide stor­data-området. Begrepet ble popularisert i 2018-boken «Overvåkings­kapitalismens tidsalder» av Shoshana Zuboff, som igjen ledet Cory Doctorow til å skrive sin bok.

Legger ved boken fordi en gjennomgang er ment å være til hjelp som nyttig bakgrunns­materiale i det generelle politiske arbeidet på dette stadig viktigere samfunnsområdet.

Boken ble oversatt til bokmål på dugnad og utgitt samtidig med den engelske utgaven. Den kan fritt lastes ned og også bestilles i trykt format på bokmål direkte fra trykkeriet9. Nærmere informasjon om utgivelsen frem­går av kolofon-siden.

Med vennlig hilsen

For Oversettergruppen

Petter Reinholdtsen (prosjektleder) og Ole-Erik Yrvin (gruppekontakt)


  1. Offentlige nettsteder sporer oss. Teknologirådet 2021-03-26. https://teknologiradet.no/offentlige-nettsteder-sporer-oss/

  2. Brombach, Harald. Tyske myndigheter må trolig slette Facebook-sidene sine innen nyttår. digi.no 2021-07-02. https://www.digi.no/artikler/tyske-myndigheter-ma-trolig-slette-facebook-sidene-sine-innen-nyttar/511719

  3. Lomas, Natasha. German government bodies urged to remove their Facebook Pages before next year. TechCrunch 2021-07-01. https://techcrunch.com/2021/07/01/german-government-bodies-urged-to-remove-their-facebook-pages-before-next-year/

  4. Gundersen, Martin. Telia og Telenor selger analyser av hvor kundene befinner seg. NRK Beta 2019-10-11. https://nrkbeta.no/2019/10/11/telia-og-telenor-selger-analyser-av-hvor-mobilbrukere-befinner-seg/

  5. de Montjoye, YA., Gambs, S., Blondel, V. med flere. On the privacy-conscientious use of mobile phone data. Sci Data 5, 180286 (2018). https://doi.org/10.1038/sdata.2018.286

  6. Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak. The European Data Protection Board 2020-04-21. https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_20200420_contact_tracing_covid_with_annex_en.pdf

  7. Lied, Henrik med flere. 8300 mobiler sporet på sykehus og krisesentre. NRK 2020-05-11. https://www.nrk.no/norge/mobilsporing_-8300-mobiler-sporet-pa-sykehus-og-krisesentre-1.15008085

  8. Barn, unge og skole. Datatilsynet 2021-07-01. https://www.datatilsynet.no/personvern-pa-ulike-omrader/skole-barn-unge/

  9. Boken kan leses via http://www.hungry.com/~pere/publisher/. I tillegg er den tilgjengelig som papirbok fra https://www.lulu.com/en/en/shop/cory-doctorow/hvordan-knuse-overvåkningskapi­talismen/ebook/product-yk8neg.html


Hvordan knuse overvåkningskapitalismen (2021)

av Cory Doctorow, se også https://craphound.com/category/destroy/ og http://www.hungry.com/~pere/publisher/.

I dag er det en utbredt tro at maskinlæring og kommersiell overvåkning kan gjøre selv en konspirasjonsteoretiker uten talegaver til en magisk manipulator med evne til å finne de sårbare blant oss og ved hjelp av argumenter skapt med kunstig intelligens, sette vettet deres ut av spill og gjøre dem til flat-jord-tilhengere, vaksineskeptikere eller til og med nynazister. Når RAND beskylder Facebook for «radikalisering», og når Facebook i sin tur sprer feilinformasjon om coronaviruset og bortforklarer det ved å henvise til algoritmene sine, er det implisitte budskapet at maskinlæring og overvåkning kan endre vår oppfattelse av hva som er sant.

Men hva om det finnes en annen forklaring? Hva om det er de materielle forutsetningene som har endret seg til fordel for disse manipulatorene? Hva om det er opplevelsen av å leve i en verden full av ekte konspirasjoner, slik de viser seg i samhandlingen mellom rike mennesker, lobbyistene deres og lovgiverne, der de enes om å begrave ubehagelige sannheter og bevis på ugjerninger, slikt som gjerne kalles korrupsjon — hva om det er denne opplevelsen som gjør folk sårbare for de tåpelige konspirasjonsteoriene?


Som vanlig, hvis du bruker Bitcoin og ønsker å vise din støtte til det jeg driver med, setter jeg pris på om du sender Bitcoin-donasjoner til min adresse 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. Merk, betaling med bitcoin er ikke anonymt. :)

July 31, 2021 11:30 AM

July 25, 2021

Ole Aamot GNOME Development Blog

GNOME Radio 12 Notes at GUADEC 2021

GUADEC 2021 took place July 21 – 25. This year’s conference was to be held online and last five days. The first two days of the conference, July 21 – 22, was dedicated to presentations. The 23 – 24 were Birds of a Feather sessions and workshops, and the last day will be for social activities.

The latest release of GNOME Internet Radio Locator 12.0.1 features 4 Free Radio Transmissions from San Francisco, California (SomaFM Groove Salad, SomaFM The Trip, SomaFM Dub Step Beyond, and SomaFM DEF CON).

See my GUADEC 2021 notes on GNOME Radio 12 building and installation on Fedora Core 34 from source and x86_64 architecture packages.

by oleaamot atJuly 25, 2021 06:39 AM

July 13, 2021

Ole Aamot GNOME Development Blog

Record Live Multiple-Location Audio immediately in GNOME Gingerblue 0.6.0

GNOME Gingerblue 0.6.0 is available and builds/runs on GNOME 40 systems such as Fedora Core 34.

It supports immediate, live audio recording in compressed Xiph.org Ogg Vorbis encoded audio files stored in the private $HOME/Music/ directory from the microphone/input line on a computer or remote audio cards through USB connection through PipeWire (www.pipewire.org) with GStreamer (gstreamer.freedesktop.org) on Fedora Core 34 (getfedora.org).

See the GNOME Gingerblue project (www.gingerblue.org) for screenshots, Fedora Core 34 x86_64 RPM package and GNU autoconf installation package (https://download.gnome.org/sources/gingerblue/0.6/gingerblue-0.6.0.tar.xz) for GNOME 40 systems and https://gitlab.gnome.org/ole/gingerblue.git for the GPLv3 source code in my GNOME Git repository.

Gingerblue music recording session screen. Click “Next” to begin session.

The default name of the musician is extracted from g_get_real_name(). You can edit the name of the musician and then click “Next” to continue ((or “Back” to start all over again) or “Finish” to skip the details).

Type the name of the musical song name. Click “Next” to continue ((or “Back” to start all over again) or “Finish” to skip any of the details).

Type the name of the musical instrument. The default instrument is “Guitar”. Click “Next” to continue ((or “Back” to start all over again) or “Finish” to skip any of the details).

Type the name of the audio line input. The default audio line input is “Mic” ( gst_pipeline_new("record_pipe") in GStreamer). Click “Next” to continue ((or “Back” to start all over again) or “Finish” to skip the details).

Enter the recording label. The default recording label is “GNOME” (Free label). Click “Next” to continue ((or “Back” to start all over again) or “Finish” to skip the details).

Enter the Computer. The default station label is a Fully-Qualified Domain Name (g_get_host_name()) for the local computer. Click “Next” to continue ((or “Back” to start all over again) or “Finish” to skip the details).

Notice the immediate, live recording file. The default immediate, live recording file name falls back to the result of g_strconcat(g_get_user_special_dir(G_USER_DIRECTORY_MUSIC), "/", gtk_entry_get_text(GTK_ENTRY(musician_entry)), "_-_", gtk_entry_get_text(GTK_ENTRY(song_entry)), "_[",g_date_time_format_iso8601 (datestamp),"]",".ogg", NULL) in gingerblue/src/gingerblue-main.c

Click on “Cancel” once in GNOME Gingerblue to stop immediate recording and click on “Cancel” once again to exit the application (or Ctrl-c in the terminal).

The following Multiple-Location Audio Recording XML file [.gingerblue] is created in G_USER_DIRECTORY_MUSIC (usually $HOME/Music/ on American English systems):

<?xml version='1.0' encoding='UTF-8'?>
<gingerblue version='0.6.0'>
<musician>Wilber</musician>
<song>Gingerblue Track 0001</song>
<instrument>Piano</instrument>
<line>Mic</line>
<label>GNOME Music</label>
<station>streaming.gnome.org</station>
<filename>/home/wilber/Music/Wilber_-_Song_-_2021-07-12T21:36:07.624570Z.ogg</filename>
</gingerblue>

You’ll find the recorded Ogg Vorbis audio files along with the Multiple-Location Audio Recording XML files in g_get_user_special_dir(G_USER_DIRECTORY_MUSIC) (usually $HOME/Music/) on GNOME 40 systems configured in the American English language.

by oleaamot atJuly 13, 2021 12:00 AM

July 07, 2021

Peter Hansteen (That Grumpy BSD Guy)

The Impending Doom of Your Operating System Going to or Past 11, Versus the Lush Oasis of Open Source Systems

Will the uncertainty over forced obsolescence of fairly recent hardware force Microsoft and Apple users to switch to open source alternatives?

During the last few weeks several items of computing hardware in our household had reached the point in their lifetime when it made sense to trade in for upgrades.

Digi.no published a Norwegian version of this articleEn skummel fremtid med operativ­system som går til 11 eller forbi, eller en rolig oase med fri programvare?

I've written articles about my last two major laptop upgrades and each time detailed (in 2010 and 2017, respectively) how to deal with hardware that was new enough that I had no way to be certain it would work optimally with my chosen operating system, OpenBSD

I have tended to jump from snapshot to snapshot, generally following whatever was -current on OpenBSD/amd64. There were other upgrades during that time, but those were straightforward enough that I did not see a need to write about them.

This time around, even though the process involved interactions with OpenBSD developers via the bugs@ mailing list and even trying two separate models from the same manufacturer before settling on what I wanted, I considered just letting this upgrade round just pass relatively undocumented. There was simply not enough drama involved in the process to make for interesting reading or an inspired writing process. 

But then came the announcements from Apple and Microsoft of their operating systems going past 11 or to 11 respectively, spaced not too many weeks apart. In both cases, the announcements indicated that the new operating system versions would not work with older hardware.

At their WWDC event in early June 2021, Apple announced new versions of their system with somewhat vague but only thinly veiled formulations that specific new features of the upcoming system would only be available on the newer ARM architecture "Apple silicon" hardware.

Then a few weeks later into June 2021, Microsoft announced their Windows 11, and the announcement included some fairly confusing statements that seemed to indicate at first that Windows 11 would only work well or at all on hardware based on Intel's 8th generation Core processors or equivalent.

Apple is almost a year into their announced two year transition from Intel-supplied processors, with a base architecture generally known as AMD64, to their own Apple-designed ARM64-based system on a chip cores. Apple has generally kept some level of support for Macs for seven years after release, and with a transition to a new architecture underway, it becomes even less surprising that support for older devices will gradually erode and that some new system features will only be available on newer model hardware.

This contrasts sharply with Microsoft's situation, with the company not really dependent on hardware sales and not with any announced or unannounced but apparent move to a different architecture. Whatever the reason for the cutback in support, the initial response from the public seemed to indicate that there now was a real fear that on installing the new software, upgrading Windows users would be faced with something like


(which is in fact an OpenBSD panic) unless they upgrade to newer hardware before trying the new software release.

The fear of abandonment seemed real and echoed the feelings I have had myself over the years when getting new hardware to run a free operating system on.

The previous articles chronicle some of the experimenting that was needed in the past to make OpenBSD work when the hardware was newer than what yet had time to reach the developers. But in the end we could always be quite certain that we could make what we were interested in work, given time and perhaps some interaction with developers, or if you were up to it, becoming a developer yourself.

Anyway, over time the chance that things would just work increased, and your sweet spot for some time was buying hardware that was released within the last couple of years before the operating system release you were installing.

Hardware drivers would generally be kept in and maintained as long as they appeared to be useful. In general a driver would only be retired from the tree if it was useful only to an architecture that was going out of support such as OpenBSD/vax which went to the attic after the OpenBSD 5.9 release in 2016.

The major lesson here is that the free systems like OpenBSD, Linux or others would keep hardware support around as long as it appears to be useful to somebody, somewhere. 

If major players like Microsoft choose to simply abandon users who do not have the latest hardware to stagnation plus only security updates, moving to a free software alternative may very well be a viable option for users who are not willing to abandon not very outdated hardware as long as their typical use case allows.

In my own experience, with hardware that has been on the market for about a year or possibly more you will encounter few to no problems making things work. My most recent Linux experience on laptops is with 9th and 11th generation Intel Core hardware, both of which will serve you well, including multimedia setups, excluding only those that explicitly tell you that you are on your own (Netflix being a case in point).

Now for an incrementally geekier part. If you are not that interested in OpenBSD, please feel free to skip.

But if you were waiting for the promised OpenBSD on newer hardware runthrough, you will get the fuller picture by reading the following and by looking up the details in the mailing list archives via the links and links in those messages.

The thread AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug chronicles the interactions from "machine installs but does not survive first boot" through finding that the machine's BIOS announced but did not actually implement some features, and the subsequent changes that went in to the mainstream OpenBSD kernel, if I remember correctly just in time to be included in OpenBSD 6.9.

However, as can be seen in ASUS ZenBook X freezes, there were problems in the DRM/xorg area that would prove too hard to debug. Do read the whole thread, it contains useful debug info for when you get into a similar situation yourself.

Returning that system to the shop for a refund while I was still fiddling with the finer points of the next system was an interesting experience in itself.

I tried to restore the system to its pre-OpenBSD state before returning it, but as it turns out the Windows 10 install image Microsoft supplies will not be able to complete an install by itself.

Rather, it will prompt you for hardware driver you are supposed to have to hand for this system.

As a result of this, the machine still had OpenBSD installed -- with my user and home directory removed and only root as an active user -- when I handed the machine in for the refund, and it was immediately clear that the support techs had never seen anything more Unixy than macOS before. Fortunately this only lead to a short delay in the issuing the refund (but I now have a 1 year PC and Mac Support contract which I do not know that I actually need).

Anyway, I had already discovered an offer for a slightly more expensive model with better features, so ordered and took delivery of the machine described in ASUS ZenBook S: SSD unrecognized, possible new iwx variant, which chronicles the relatively light debugging needed to get the system in shape.

In short, after receiving the package with the new machine late in the afternoon, I spent a few hours trying to work around a few items that lead to rather puzzling failures at first, but fortunately they were all relatively easy to fix with a little help from OpenBSD developers who read the bugs@ list.

The first hurdle was that the system apparently did not recognize the built in SSD. This turned out to a matter of finding the BIOS option for turning off RAID controller functionality, which anyway does not make a whole lot of sense in a system where it is physically impossible to fit more than one storage device on a permanent basis.

The option turned out to live in the BIOS' Advanced menu, labeled VMD setup menu, where you set the Enable VMD controller option to Disabled. Once that is done, the SSD shows up as a regular NVMe device:

nvme0 at pci3 dev 0 function 0 "Intel NVMe" rev 0x03: msix, NVMe 1.3
nvme0: INTEL SSDPEKNW010T8, firmware 004C, serial BTNH03460GYE1P0B
scsibus1 at nvme0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: <NVMe, INTEL SSDPEKNW01, 004C>
sd0: 976762MB, 512 bytes/sector, 2000409264 sectors

This made it possible to install on the internal SSD proper, and the next issue was that this 11th generation Intel Core system needed a newer revision (version 5.10) of the Linux-derived DRM code. At the time (and still at the time of writing) Jonathan Gray maintained an as-not-yet-committed branch of the OpenBSD kernel with the code I needed in. The reason this DRM code version was not committed to the main tree was that the newer code caused some regressions on older hardware.

On my system, it looked like the stock kernel would panic when loading the iwx(4) driver, but booting the test kernel Jonathan supplied cured that problem, and I have been running once a week checkouts of the drm510 kernel on top of sysupgraded snapshots since.

However, even with the iwx(4) driver now loading, the wireless network device did not work. 

Running doas fw_update -v revealed that several of the relevant firmware files had been corrupted, and after doas fw_update -d iwx and re-installing (doas fw_update iwx), doas /etc/netstart iwx0 worked as expected and with excellent performance.

In the meantime it had turned out that not only was the audio parts of the system in fact supported (it only needed a one line patch to enable it), only minor manipulation to configuration files would make the audio output signal switch correctly between the internal speaker and my headphones, and that for video conferencing a low cost full duplex USB headset was the better choice.

So now I have a gorgeous, lightweight 13.9 inch laptop running OpenBSD with Xorg running with a 3300x2200 pixel resolution and everything I care about working. With a little attention to proper testing, we have reason to believe that all of this will be properly supported without regression for older hardware versions in the upcoming OpenBSD 7.0 release.

As I had hinted earlier, you may very well find yourself better served and supported by the open source operating system of your choice and its developers and users than you can reasonably expect from the commercial, proprietary options.

If you have questions about anything in this article, OpenBSD or other free systems, please let me know in comments here, seek out a local-to-you user group (the ones I am most involved in are NUUG, the national Norwegian Unix User Group, and BLUG, the Bergen (BSD and) Linux User Group), or drop me an email. If you choose the last option, please read my read me first document before sending a second message.




Update 2021-07-07: As reported in the following tweet, the DRM 5.10 update is now in, and I can go back to quiet sysupgrade(8) from snapshot to snapshot:

Following this commit https://t.co/Qn8QLQcbmH (the DRM 5.10 update), a simple sysupgrade was all that was needed for the machine from https://t.co/znXV6lRLNn to just work with the latest #OpenBSD snapshot. Thanks again to jsg@ and all #OpenBSD developers!

— Peter N. M. Hansteen (@pitrh) July 7, 2021

Which also means OpenBSD 7.0 will seriously rock on this and similar machines.

by Peter N. M. Hansteen (noreply@blogger.com) atJuly 07, 2021 08:36 AM

May 15, 2021

NUUG news

Vet du hva du mister når du bare klikker OK for å komme i gang med å bruke noe?

Retten til privatlivets fred, retten til å reparere og retten til å velge verktøy er sider av samme sak. En ny rettsavgjørelse i Italia kan hjelpe oss å vinne tilbake rettigheter vi ble manipulert til å si fra oss.

Du tenker nok ikke på det så ofte, men om du er en vanlig IT-bruker i et industrialisert land har du sannsynligvis blitt lurt til å si fra deg rettigheter. Dette skjer i et slikt omfang at menneskerettsinteresserte burde være bekymret.

Tenk på når du skal ta i bruk noe du er interessert i, enten det er en datamaskin av noe slag som for eksempel PC, nettbrett eller telefon, eller en nettbasert tjeneste.

La oss først se nærmere på hva som skjer når du får ny datamaskin, nettbrett eller telefon i hus. Noe av det første som skjer etter at du har slått på strømmen for den nye enheten, og helt sikkert før du får mulighet til å bruke dingsen til det du ønsker å gjøre, er at du må godta en juridisk bindende avtale som er utformet av og for de som har produsert utstyret. For å kunne bruke det du har kjøpt, må du godta en avtale som styrer hva du kan bruke enheten til.

I mange tilfeller er det flere slike avtaler som blir presentert, hver med sin egen registrering av om du godtar eller ikke.

Noen av disse avtalene begrenser hva du kan bruke enheten til, mens andre gir leverandøren eller noen som samarbeider med leverandøren lov til å samle inn informasjon om deg og hva du foretar deg med enheten.

Mange av disse ja/nei-spørsmålene gir inntrykk av at du har mulighet til å nekte å godta, men du vil se at du sannsynligvis ikke kommer videre til å ha en gjenstand som er reelt brukbar til tiltenkt bruk før du har godtatt alle disse avtalene.

En av de mest tydelige konsekvensene av COVID 19-krisen er at en større andel av befolkningen ble presset over til nesten helt digital tilværelse, der kommunikasjon både i jobb- og skolesammenheng foregår via digitale enheter og via tjenester som leveres på vilkår av avtaler som er diktert av leverandørene. For noen av oss har tilværelsen vært nær heldigital i en årrekke allerede, men for mange er det en ny situasjon og det går langsomt opp for flere at viktige friheter og rettigheter kan være i ferd med å gå tapt.

Problemstillingen er ikke ny. Mange av oss i IT-miljøer har lenge advart mot at det vi regner som menneskerettigheter eller borgerrettigheter er i ferd med å bli gradvis slipt vekk til fordel for enkelte bedrifter og deres eiere.

Når du slår på en ny datamaskin eller telefon for første gang, blir du sannsynligvis nesten med en gang bedt om å godta en "sluttbrukerlisens" for operativsystemet, altså programvaren som styrer enheten. I sin enkleste form er en lisens et dokument som angir vilkårene for at noen andre enn den som har laget et åndsverk (her programvaren) får tillatelse til å lage eksemplarer av verket. Men i mange tilfeller inneholder lisensdokumentet mer detaljerte og omfattende vilkår. Ofte er lisensavtalen formulert som om du har rett til å avslå å bruke operativsystemet og slette eksemplarer som følger med eller levere tilbake fysiske eksemplarer og få tilbake pengene, men at du kan fortsette å bruke den fysiske maskinen. En del av oss som har kjøpt PCer og annet har vært i stand til å installere et annet system enn det som ble levert med maskinen, og valgt å leve det digitale livet ved hjelp av frie alternativer som for eksempel Linux eller OpenBSD. En del av oss gjør dette for å få mer direkte kontroll over verktøyene vi bruker.

Om vi har forsøkt å få tilbake penger for en ubrukt operativsystemlisens har de fleste av oss aldri klart å få det til. Men det skal vi komme tilbake til.

Om du har klart å installere et fritt alternativ til det operativsystemet som enheten ble levert med, har du slått et slag for retten til å velge verktøy og retten til å reparere og råde over dine egne eiendeler. Men dessverre er ikke dette det eneste punktet i ditt digitale liv der rettighetene dine er i fare.

Uansett om du godtok sluttbrukerlisensen eller ikke, kommer du fort ut for for programvare eller nettbaserte tjenester som presenterer sine egne sluttbrukeravtaler. Det er en stor sjanse for at du bare klikker OK uten å lese vilkårene i avtalen.

Ta gjerne nå en pause for å sjekke hva du faktisk har gått med på. Sannsynligvis finner du at både operativsystemleverandører og sosiale medier-tjenester har fått deg til å gi dem tillatelse til å registrere hva du foretar deg når du bruker systemet eller tjenesten. Ta gjerne tiden til å sjekke alle produkter og tjenester du har registrert deg hos. Det er sannsynlig at ikke bare en, men de aller fleste av de tjenestene og produktene du bruker på en nett-tilkoblet enhet har gitt seg selv retten til å fange inn og lagre data om hva du foretar deg. Hvis du bruker enheten til noe som helst privat eller følsomt, er det verd å se nøye etter hvilke konsekvenser disse avtalene har for din rett til privatliv og beskyttelse av privatsfæren.

På papiret (om vi skal uttrykke oss gammeldags) har vi som bor i EU og EØS-land rett til å få utlevert data som er lagret om oss og eventuelt få rettet feil eller til og med få slettet data i samsvar med EUs personvernforordning (GDPR). Hvis det du fant ut mens du sjekket avtalene mens du tok pause fra å lese denne teksten gjør deg usikker eller bekymret er det god grunn til å ta i bruk retten til innsyn, utlevering, retting eller sletting. Om du ikke får meningsfylt svar, ta kontakt med Datatilsynet eller Forbrukertilsynet, som bør stå klare til å hjelpe.

Men hva så med retten til å reparere eller retten til å velge verktøy? Jo, også på det feltet er det grunn til håp. Etter en omfattende prosess kom nemlig en domstol i Italia frem til at ikke bare hadde en Linux-entusiast rett til å installere Linux på sin nye Lenovo-datamaskin, slik at kunden også hadde rett til å refundert prisen for operativsystemet som ikke ville bli brukt. Og siden Lenovo hadde prøvd å ikke etterleve sine forpliktelser som var angitt i sluttbrukerlisensen som ble presentert for kunden, ble de ilagt en bot på 20 000 Euro.

En slik rettsavgjørelse er ikke direkte presedensskapende for andre europeiske land, og det finnes avgjørelser i andre land som ikke ga kunden medhold i at operativsystem og datamaskin kunne behandles som separate varer. Vi i den norske Unix-brukergruppen (Norwegian Unix User Group - NUUG) deltar nå i et samarbeid som koordineres av Free Software Foundation Europe (FSFE) for å forsvare og styrke din og min rett til privatliv, rett til å reparere og rett til å velge verktøy for å styre vår digitale tilværelse.

Hvis noe av det du nå har lest bekymrer deg, gjør deg forvirret, sint eller bare engasjert for å styrke våre borger- og menneskeretter i den digitale tilværelsen vil vi bli glade for å høre fra deg.

Peter N. M. Hansteen
Styreleder i Norwegian Unix User Group (NUUG)

Den italienske rettsavgjørelsen som gir oss håp er beskrevet på FSFEs nettsted: Refund of pre-installed Windows: Lenovo must pay 20,000 euros in damages

An English version is available as Are you aware what you lose by just clicking OK to get started using something?

May 15, 2021 11:10 AM

May 11, 2021

Nicolai Langfeldt

DLNA servers for our Samsung TV on Linux

We have a Samsung Smart TV, I like it. We also have a cable box, a BluRay player (because sometimes we borrow movies at the library and anyone in the family needs to be able to play them with no help from dad), and a Chromecast.  All three HDMI inputs on the TV are used.

Samsung was pretty big on DLNA, a UPnP based protocol for media playback. Now it's not a feature they tout a lot: People want Netflix. Samsung also had very good codec support from the start which reduces the need for transcoding greatly.  They still have the DLNA client builtin in their TVs and the codec support is even better now.  So this solves the in-house streaming problem very neatly without needing a extra box by the TV to do it. The server in the basement ought to be enough when the TV had DLNA.

I understand that DLNA is a bit low featured in 2021: no on screen movie/episode synopsis, not very slick navigation and on screen controls for everything. But it's enough. DLNA is right featured. The Samsung DLNA client has very nice movie navigation and on screen menus for subtitle selection. And I don't particularly want a TV box though it would certainly play all kinds of video with no issues at all and support subs better and have a nice graphical interface. It seems I'm not in tune with the world on this though: DLNA servers seem to be more rare than before.

Since the start around 2010 I've used tvMobili, a closed source but fully functional DLNA server software that just worked with our TV, including on screen subtitles without transcoding. It also just worked with phone based DLNA software. Since my wife is deaf and not all the kids are that steady in english yet subtitles are a required feature. Subtitles are also nice for late night TV viewing with low volume.

Recently the disk the tvMobili software stored its database on went full and the database went corrupt.  I tidied the disk and nuked the database. Unfortunately that reset the software and it gave me it's out of the box experience: "Please create your account at tvMobili to proceed". tvMobili, the company, gave up in 2013. There was no registration service running any more and I could not get past the registration screen. And also I had no backup of that directory since it only contained stuff I could reconstruct anyway. I thought. (I realize I might try to write the registration service and run it locally, but maybe time to try something new?).

So what to do for in-house streaming now then? This is important to me:

The candidates.

Also I'm not sure I want to depend on TV-apps since they tend to be retired before we want to retire the TV.

So Plex didn't work that well for me.  I asked around and were told of some open source alternatives:
To summarize:
... sort of odd that the DNLA server software for 2021 isn't quite up to 2016 standards. Not even the leading(?) commercial contender.

by nicolai (noreply@blogger.com) atMay 11, 2021 12:54 PM

May 04, 2021

Nicolai Langfeldt

New Linux on old hardware

Since our family relies on the servers in our basement for email, music, movies, and so on it's been bothering me that we have no extra hardware in case something goes wrong.

I've been given two old Dell machines, I want to use one for stuff and one as spares in case something breaks.

Both needed reinstalling: I like Ubuntu and made myself a memory stick with Ubutnus usb-creator software.  The machines never managed to boot of those.  The Ubuntu server ISOs are too large to fit on a CD. Found ubuntus netboot ISOs for 18.04 which fits a CD ten times over.  Again they didn't boot from the memory stick nor off a CD with various error messages or just passing it by and booting off the old OS on the harddrive.

After a while I recalled "unetbootin" - a old, but still updated - tool to make memory sticks from ISO images. It currently lives here: https://unetbootin.github.io/

I had to repartition my memory stick (cfdisk /dev/sdc in my case) and make a msdos filesystem (mkfs.msdos /dev/sdc1) and mount it.

Then unetbootin could make it bootable and indeed my quite old hardware was able to see my memory stick as a hard drive and boot for it with no further issues.

Win of the day.


by nicolai (noreply@blogger.com) atMay 04, 2021 08:29 PM

March 07, 2021

NUUG Foundation

Reisestipend - 2021

NUUG Foundation utlyser reisestipender for 2021. Søknader kan sendes inn til enhver tid.

March 07, 2021 09:46 AM

September 22, 2020

Dag-Erling Smørgrav

wtf, zsh

wtf, zsh

% uname -sr
FreeBSD 12.1-RELEASE-p10
% for sh in sh csh bash zsh ; do printf "%-8s" $sh ; $sh -c 'echo \\x21' ; done 
sh      \x21
csh     \x21
bash    \x21
zsh     !
% cowsay wtf, zsh       
 __________ 
< wtf, zsh >
 ---------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

I mean. Bruh. I know it’s intentional & documented & can be turned off, but every other shell defaults to POSIX semantics…

BTW:

% ln -s =zsh /tmp/sh
% /tmp/sh -c 'echo \x21'
\x21

by Dag-Erling Smørgrav atSeptember 22, 2020 01:11 PM

September 18, 2020

NUUG events video archive

Introduksjon til bygging av Debianpakker

September 18, 2020 05:15 AM

August 21, 2020

Dag-Erling Smørgrav

Netlink, auditing, and counting bytes

I’ve been messing around with Linux auditing lately, because of reasons, and ended up having to replicate most of libaudit, because of other reasons, and in the process I found bugs in both the kernel and userspace parts of the Linux audit subsystem.

Let us start with what Netlink is, for readers who aren’t very familiar with Linux: it is a mechanism for communicating directly with kernel subsystems using the BSD socket API, rather than by opening device nodes or files in a synthetic filesystem such as /proc. It has pros and cons, but mostly pros, especially as a replacement for ioctl(2), since Netlink sockets are buffered, can be poll(2)ed, and can more easily accommodate variable-length messages and partial reads.

Note: all links to source code in this post point to the versions used in Ubuntu 18.04 as of 2020-08-21: kernel 5.4, userspace 2.8.2.

Netlink messages start with a 16-byte header which looks like this: (source, man page)

struct nlmsghdr {
	__u32		nlmsg_len;	/* Length of message including header */
	__u16		nlmsg_type;	/* Message content */
	__u16		nlmsg_flags;	/* Additional flags */
	__u32		nlmsg_seq;	/* Sequence number */
	__u32		nlmsg_pid;	/* Sending process port ID */
};

The same header also provides a few macros to help populate and interpret Netlink messages: (source, man page)

#define NLMSG_ALIGNTO	4U
#define NLMSG_ALIGN(len) ( ((len)+NLMSG_ALIGNTO-1) & ~(NLMSG_ALIGNTO-1) )
#define NLMSG_HDRLEN	 ((int) NLMSG_ALIGN(sizeof(struct nlmsghdr)))
#define NLMSG_LENGTH(len) ((len) + NLMSG_HDRLEN)
#define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len))
#define NLMSG_DATA(nlh)  ((void*)(((char*)nlh) + NLMSG_LENGTH(0)))
#define NLMSG_NEXT(nlh,len)	 ((len) -= NLMSG_ALIGN((nlh)->nlmsg_len), \
				  (struct nlmsghdr*)(((char*)(nlh)) + NLMSG_ALIGN((nlh)->nlmsg_len)))
#define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \
			   (nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \
			   (nlh)->nlmsg_len <= (len))
#define NLMSG_PAYLOAD(nlh,len) ((nlh)->nlmsg_len - NLMSG_SPACE((len)))

Going by these definitions and the documentation, it is clear that the length field of the message header reflects the total length of the message, header included. What is somewhat less clear is that Netlink messages are supposed to be padded out to a multiple of four bytes before transmission or storage.

The Linux audit subsystem not only breaks these rules, but does not even agree with itself on precisely how to break them.

The userspace tools (auditctl(8), auditd(8)…) all use libaudit to communicate with the kernel audit subsystem. When passing a message of length size to the kernel, libaudit copies the payload into a large pre-zeroed buffer, sets the type, flags, and sequence number fields to the appropriate values, sets the pid field to zero (which is probably a bad idea but, strictly speaking, permitted), and finally sets the length field to NLMSG_SPACE(size), which evaluates to sizeof(struct nlmsghdr) + size rounded up to a multiple of four. It then writes that exact number of bytes to the socket.

Bug #1: The length field should not be rounded up; the purpose of the NLMSG_SPACE() and NLMSG_NEXT() macros is to ensure proper alignment of subsequent message headers when multiple messages are stored or transmitted consecutively. The length field should be computed using NLMSG_LENGTH(), which simply adds the length of the header to its single argument.

Note: to my understanding, Netlink supports sending multiple messages in a single send / receive provided that they are correctly aligned, that they all have the NLM_F_MULTI flag set, and that the last message in the sequence is a zero-length message of type NLMSG_DONE. The audit subsystem does not use this feature.

Moving on: NETLINK_AUDIT messages essentially fall into one of four categories:

  1. Requests from userspace; for instance, an AUDIT_GET message which requests the current status of the audit subsystem, an AUDIT_SET message which changes parameters, or an AUDIT_LIST_RULES message which requests a list of currently active auditing rules.
  2. Responses from the kernel; these usually have the same type as the request. For instance, the kernel will respond to an AUDIT_GET request with a message of the same type containing a struct audit_status, and to an AUDIT_LIST_RULES request with a sequence of messages of the same type each containing a single struct audit_rule_data.
  3. Errors and acknowledgements. These use standard Netlink message types: NLMSG_ERROR in response to an invalid request (or a valid request with the NLM_F_ACK flag set), or NLMSG_DONE at the end of a multi-part response.
  4. Audit data. Every event that matches an auditing rule will trigger a series of messages with varying types: usually one which describes the system call that triggered the event, one each for every file or directory affected by the call, one or more describing the process, etc. Each message consists of a header of the form audit(timestamp:serial):� which uniquely identifies the event, followed by a space-separated list of key-value pairs. The final message has the type AUDIT_EOE and has the same header, trailing space included, but no data.

The kernel pads responses, errors and acknowledgements, but does not include that padding in the length reported in the message header. So far, so good. However…

Bug #2: Audit data messages are sent from the kernel without padding.

This is not critical, but it does mean that an implementation that batches up incoming messages and stores them consecutively must take extra care to keep them properly aligned.

Bug #3: The length field on audit data messages does not include the length of the header.

This is jaw-dropping. It is so fundamentally wrong. It means that anyone who wants to talk to the audit subsystem using their own code instead of libaudit will have to add a workaround to the Netlink layer of their stack to either fix or ignore the error, and apply that workaround only for certain message types.

How has this gone unnoticed? Well, libaudit doesn’t do much input validation. It relies on the NLMSG_OK() macro, which checks only three things:

  1. That the length of the buffer (as returned by recvfrom(2), for instance) is no less than the length of a Netlink message header.
  2. That the length field in the message header is no less than the length of a Netlink message header.
  3. That the length field in the message header is less than or equal to the length of the buffer.

Since every audit data message, even the empty AUDIT_EOE message, begins with a timestamp and serial number, the length of the payload is never less than 25-30 bytes, and NLMSG_OK() is always satisfied. And since the audit subsystem never sends multiple messages in a single send / receive, it does not matter that NLMSG_NEXT() will be off by 16 bytes.

Consumers of libaudit don’t notice either because they never look at the header; libaudit wraps the message in its own struct audit_reply with its own length and type fields and pointers of the appropriate types for messages that contain binary data (this is a bad idea for entirely different reasons which we won’t go into here). The only case in which the caller needs to know the length of the message is for audit events, when the length field just happens to be the length of the payload, just like the caller expects.

The odds of these bugs getting fixed is approximately zero, because existing applications will break in interesting ways if the kernel starts setting the length field correctly.

Turing wept.

THIS IS WHY WE CAN’T HAVE NICE THINGS

by Dag-Erling Smørgrav atAugust 21, 2020 04:33 PM

May 19, 2020

NUUG news

NUUG bygger bokskanner - arbeidet er i gang

Det finnes millioner av bøker der vernetiden er utløpt. Noen av dem er norske bøker, og endel av dem finnes ikke tilgjengelig digitalt. For å forsøke å gjøre noe med det siste, har NUUG vedtatt å få bygget en bokskanner. Utformingen er basert på en enkel variant i plast (byggeinstrukser), men vil bli laget i aluminium for lengre levetid.

Oppdraget med å bygge scanneren er gitt til våre venner i Oslo Sveisemek, som er godt igang med arbeidet. Her ser du en skisse over konstruksjonen:

Konstruksjonsskisse

Grunnrammen er montert, men det gjenstår fortsatt en god del:

Montering av grunnrammen

Tanken er at medlemmer og andre skal kunne låne eller leie bokskanner ved behov, og de av oss som er interessert kan gå igang med å digitalisere bøker med OCR og pågangsmot. Ta kontakt med aktive (at) nuug.no hvis dette er noe for deg, eller stikk innom #nuug.

(Fotograf er Jonny Birkelund)

May 19, 2020 06:00 PM

December 15, 2019

NUUG Foundation

Reisestipend - 2020

NUUG Foundation utlyser reisestipender for 2020. Søknader kan sendes inn til enhver tid.

December 15, 2019 09:46 AM

May 31, 2018

Kevin Brubeck Unhammer

Kan samisk brukes i det offentlige rom?

Hvis vi hadde laget et program som oversatte fra norsk til samisk, ville resultatet ha vært en samisk som er minst like dårlig som den norsken vi er i stand til å lage nå. Norsk og samisk er grammatisk sett svært ulike, og det er vanskelig å få til god samisk på grunnlag av norsk. Et slikt program vil føre til publisering av en hel masse svært dårlig samisk. En situasjon der mesteparten av all samisk publisert på internett kommer fra våre program fortoner seg som et mareritt. Det ville rett og slett ha ødelagt den samiske skriftkulturen.

Sjå kronikken: https://www.nordnorskdebatt.no/samisk-sprak/digitalisering/facebook/kan-samisk-brukes-i-det-offentlige-rom/o/5-124-48030

by unhammer atMay 31, 2018 09:00 AM

October 23, 2017

Espen Braastad

ZFS NAS using CentOS 7 from tmpfs

Following up on the CentOS 7 root filesystem on tmpfs post, here comes a guide on how to run a ZFS enabled CentOS 7 NAS server (with the operating system) from tmpfs.

Hardware

Preparing the build environment

The disk image is built in macOS using Packer and VirtualBox. Virtualbox is installed using the appropriate platform package that is downloaded from their website, and Packer is installed using brew:

$ brew install packer

Building the disk image

Three files are needed in order to build the disk image; a Packer template file, an Anaconda kickstart file and a shell script that is used to configure the disk image after installation. The following files can be used as examples:

Create some directories:

$ mkdir ~work/centos-7-zfs/
$ mkdir ~work/centos-7-zfs/http/
$ mkdir ~work/centos-7-zfs/scripts/

Copy the files to these directories:

$ cp template.json ~work/centos-7-zfs/
$ cp ks.cfg ~work/centos-7-zfs/http/
$ cp provision.sh ~work/centos-7-zfs/scripts/

Modify each of the files to fit your environment.

Start the build process using Packer:

$ cd ~work/centos-7-zfs/
$ packer build template.json

This will download the CentOS 7 ISO file, start an HTTP server to serve the kickstart file and start a virtual machine using Virtualbox:

Packer installer screenshot

The virtual machine will boot into Anaconda and run through the installation process as specified in the kickstart file:

Anaconda installer screenshot

When the installation process is complete, the disk image will be available in the output-virtualbox-iso folder with the vmdk extension.

Packer done screenshot

The disk image is now ready to be put in initramfs.

Putting the disk image in initramfs

This section is quite similar to the previous blog post CentOS 7 root filesystem on tmpfs but with minor differences. For simplicity reasons it is executed on a host running CentOS 7.

Create the build directories:

$ mkdir /work
$ mkdir /work/newroot
$ mkdir /work/result

Export the files from the disk image to one of the directories we created earlier:

$ export LIBGUESTFS_BACKEND=direct
$ guestfish --ro -a packer-virtualbox-iso-1508790384-disk001.vmdk -i copy-out / /work/newroot/

Modify /etc/fstab:

$ cat > /work/newroot/etc/fstab << EOF
tmpfs       /         tmpfs    defaults,noatime 0 0
none        /dev      devtmpfs defaults         0 0
devpts      /dev/pts  devpts   gid=5,mode=620   0 0
tmpfs       /dev/shm  tmpfs    defaults         0 0
proc        /proc     proc     defaults         0 0
sysfs       /sys      sysfs    defaults         0 0
EOF

Disable selinux:

echo "SELINUX=disabled" > /work/newroot/etc/selinux/config

Disable clearing the screen on login failure to make it possible to read any error messages:

mkdir /work/newroot/etc/systemd/system/getty@.service.d
cat > /work/newroot/etc/systemd/system/getty@.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF

Now jump to the Initramfs and Result sections in the CentOS 7 root filesystem on tmpfs and follow those steps until the end when the result is a vmlinuz and initramfs file.

ZFS configuration

The first time the NAS server boots on the disk image, the ZFS storage pool and volumes will have to be configured. Refer to the ZFS documentation for information on how to do this, and use the following command only as guidelines.

Create the storage pool:

$ sudo zpool create data mirror sda sdb mirror sdc sdd

Create the volumes:

$ sudo zfs create data/documents
$ sudo zfs create data/games
$ sudo zfs create data/movies
$ sudo zfs create data/music
$ sudo zfs create data/pictures
$ sudo zfs create data/upload

Share some volumes using NFS:

zfs set sharenfs=on data/documents
zfs set sharenfs=on data/games
zfs set sharenfs=on data/music
zfs set sharenfs=on data/pictures

Print the storage pool status:

$ sudo zpool status
  pool: data
 state: ONLINE
  scan: scrub repaired 0B in 20h22m with 0 errors on Sun Oct  1 21:04:14 2017
config:

	NAME        STATE     READ WRITE CKSUM
	data        ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    sdd     ONLINE       0     0     0
	    sdc     ONLINE       0     0     0
	  mirror-1  ONLINE       0     0     0
	    sda     ONLINE       0     0     0
	    sdb     ONLINE       0     0     0

errors: No known data errors

October 23, 2017 11:20 PM

February 13, 2017

Mimes brønn

En innsynsbrønn full av kunnskap

Mimes brønn er en nettjeneste som hjelper deg med å be om innsyn i offentlig forvaltning i tråd med offentleglova og miljøinformasjonsloven. Tjenesten har et offentlig tilgjengelig arkiv over alle svar som er kommet på innsynsforespørsler, slik at det offentlige kan slippe å svare på de samme innsynshenvendelsene gang på gang. Du finner tjenesten på

https://www.mimesbronn.no/

I følge gammel nordisk mytologi voktes kunnskapens kilde av Mime og ligger under en av røttene til verdenstreet Yggdrasil. Å drikke av vannet i Mimes brønn ga så verdifull kunnskap og visdom at den unge guden Odin var villig til å gi et øye i pant og bli enøyd for å få lov til å drikke av den.

Nettstedet vedlikeholdes av foreningen NUUG og er spesielt godt egnet for politisk interesserte personer, organisasjoner og journalister. Tjenesten er basert på den britiske søstertjenesten WhatDoTheyKnow.com, som allerede har gitt innsyn som har resultert i dokumentarer og utallige presseoppslag. I følge mySociety for noen år siden gikk ca 20 % av innsynshenvendelsene til sentrale myndigheter via WhatDoTheyKnow. Vi i NUUG håper NUUGs tjeneste Mimes brønn kan være like nyttig for innbyggerne i Norge.

I helgen ble tjenesten oppdatert med mye ny funksjonalitet. Den nye utgaven fungerer bedre på små skjermer, og viser nå leveringsstatus for henvendelsene slik at innsender enklere kan sjekke at mottakers epostsystem har bekreftet mottak av innsynshenvendelsen. Tjenesten er satt opp av frivillige i foreningen NUUG på dugnad, og ble lansert sommeren 2015. Siden den gang har 121 brukere sendt inn mer enn 280 henvendelser om alt fra bryllupsutleie av Operaen og forhandlinger om bruk av Norges topp-DNS-domene .bv til journalføring av søknader om bostøtte, og nettstedet er en liten skattekiste av interessant og nyttig informasjon. NUUG har knyttet til seg jurister som kan bistå med å klage på manglende innsyn eller sviktende saksbehandling.

– «NUUGs Mimes brønn var uvurderlig da vi lyktes med å sikre at DNS-toppdomenet .bv fortsatt er på norske hender,» forteller Håkon Wium Lie.

Tjenesten dokumenterer svært sprikende praksis i håndtering av innsynshenvendelser, både når det gjelder responstid og innhold i svarene. De aller fleste håndteres raskt og korrekt, men det er i flere tilfeller gitt innsyn i dokumenter der ansvarlig etat i ettertid ønsker å trekke innsynet tilbake, og det er gitt innsyn der sladdingen har vært utført på en måte som ikke skjuler informasjonen som skal sladdes.

– «Offentlighetsloven er en bærebjelke for vårt demokrati. Den bryr seg ikke med hvem som ber om innsyn, eller hvorfor. Prosjektet Mimes brønn innebærer en materialisering av dette prinsippet, der hvem som helst kan be om innsyn og klage på avslag, og hvor dokumentasjon gjøres offentlig. Dette gjør Mimes Brønn til et av de mest spennende åpenhetsprosjektene jeg har sett i nyere tid.» forteller mannen som fikk åpnet opp eierskapsregisteret til skatteetaten, Vegard Venli.

Vi i foreningen NUUG håper Mimes brønn kan være et nyttig verktøy for å holde vårt demokrati ved like.

by Mimes Brønn atFebruary 13, 2017 02:07 PM

January 06, 2017

Espen Braastad

CentOS 7 root filesystem on tmpfs

Several years ago I wrote a series of posts on how to run EL6 with its root filesystem on tmpfs. This post is a continuation of that series, and explains step by step how to run CentOS 7 with its root filesystem in memory. It should apply to RHEL, Ubuntu, Debian and other Linux distributions as well. The post is a bit terse to focus on the concept, and several of the steps have potential for improvements.

The following is a screen recording from a host running CentOS 7 in tmpfs:

Sensor

Build environment

A build host is needed to prepare the image to boot from. The build host should run CentOS 7 x86_64, and have the following packages installed:

yum install libvirt libguestfs-tools guestfish

Make sure the libvirt daemon is running:

systemctl start libvirtd

Create some directories that will be used later, however feel free to relocate these to somewhere else:

mkdir -p /work/initramfs/bin
mkdir -p /work/newroot
mkdir -p /work/result

Disk image

For simplicity reasons we’ll fetch our rootfs from a pre-built disk image, but it is possible to build a custom disk image using virt-manager. I expect that most people would like to create their own disk image from scratch, but this is outside the scope of this post.

Use virt-builder to download a pre-built CentOS 7.3 disk image and set the root password:

virt-builder centos-7.3 -o /work/disk.img --root-password password:changeme

Export the files from the disk image to one of the directories we created earlier:

guestfish --ro -a /work/disk.img -i copy-out / /work/newroot/

Clear fstab since it contains mount entries that no longer apply:

echo > /work/newroot/etc/fstab

SELinux will complain about incorrect disk label at boot, so let’s just disable it right away. Production environments should have SELinux enabled.

echo "SELINUX=disabled" > /work/newroot/etc/selinux/config

Disable clearing the screen on login failure to make it possible to read any error messages:

mkdir /work/newroot/etc/systemd/system/getty@.service.d
cat > /work/newroot/etc/systemd/system/getty@.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF

Initramfs

We’ll create our custom initramfs from scratch. The boot procedure will be, simply put:

  1. Fetch kernel and a custom initramfs.
  2. Execute kernel.
  3. Mount the initramfs as the temporary root filesystem (for the kernel).
  4. Execute /init (in the initramfs).
  5. Create a tmpfs mount point.
  6. Extract our CentOS 7 root filesystem to the tmpfs mount point.
  7. Execute switch_root to boot on the CentOS 7 root filesystem.

The initramfs will be based on BusyBox. Download a pre-built binary or compile it from source, put the binary in the initramfs/bin directory. In this post I’ll just download a pre-built binary:

wget -O /work/initramfs/bin/busybox https://www.busybox.net/downloads/binaries/1.26.1-defconfig-multiarch/busybox-x86_64

Make sure that busybox has the execute bit set:

chmod +x /work/initramfs/bin/busybox

Create the file /work/initramfs/init with the following contents:

#!/bin/busybox sh

# Dump to sh if something fails
error() {
	echo "Jumping into the shell..."
	setsid cttyhack sh
}

# Populate /bin with binaries from busybox
/bin/busybox --install /bin

mkdir -p /proc
mount -t proc proc /proc

mkdir -p /sys
mount -t sysfs sysfs /sys

mkdir -p /sys/dev
mkdir -p /var/run
mkdir -p /dev

mkdir -p /dev/pts
mount -t devpts devpts /dev/pts

# Populate /dev
echo /bin/mdev > /proc/sys/kernel/hotplug
mdev -s

mkdir -p /newroot
mount -t tmpfs -o size=1500m tmpfs /newroot || error

echo "Extracting rootfs... "
xz -d -c -f rootfs.tar.xz | tar -x -f - -C /newroot || error

mount --move /sys /newroot/sys
mount --move /proc /newroot/proc
mount --move /dev /newroot/dev

exec switch_root /newroot /sbin/init || error

Make sure it is executable:

chmod +x /work/initramfs/init

Create the root filesystem archive using tar. The following command also uses xz compression to reduce the final size of the archive (from approximately 1 GB to 270 MB):

cd /work/newroot
tar cJf /work/initramfs/rootfs.tar.xz .

Create initramfs.gz using:

cd /work/initramfs
find . -print0 | cpio --null -ov --format=newc | gzip -9 > /work/result/initramfs.gz

Copy the kernel directly from the root filesystem using:

cp /work/newroot/boot/vmlinuz-*x86_64 /work/result/vmlinuz

Result

The /work/result directory now contains two files with file sizes similar to the following:

ls -lh /work/result/
total 277M
-rw-r--r-- 1 root root 272M Jan  6 23:42 initramfs.gz
-rwxr-xr-x 1 root root 5.2M Jan  6 23:42 vmlinuz

These files can be loaded directly in GRUB from disk, or using iPXE over HTTP using a script similar to:

#!ipxe
kernel http://example.com/vmlinuz
initrd http://example.com/initramfs.gz
boot

January 06, 2017 08:34 PM

July 15, 2016

Mimes brønn

Hvem har drukket fra Mimes brønn?

Mimes brønn har nå vært oppe i rundt et år. Derfor vi tenkte det kunne være interessant å få en kortfattet statistikk om hvordan tjenesten er blitt brukt.

I begynnelsen av juli 2016 hadde Mimes brønn 71 registrerte brukere som hadde sendt ut 120 innsynshenvendelser, hvorav 62 (52%) var vellykkede, 19 (16%) delvis vellykket, 14 (12%) avslått, 10 (8%) fikk svar at organet ikke hadde informasjonen, og 12 henvendelser (10%; 6 fra 2016, 6 fra 2015) fortsatt var ubesvarte. Et fåtall (3) av hendvendelsene kunne ikke kategoriseres. Vi ser derfor at rundt to tredjedeler av henvendelsene var vellykkede, helt eller delvis. Det er bra!

Tiden det tar før organet først sender svar varierer mye, fra samme dag (noen henvendelser sendt til Utlendingsnemnda, Statens vegvesen, Økokrim, Mediatilsynet, Datatilsynet, Brønnøysundregistrene), opp til 6 måneder (Ballangen kommune) eller lenger (Stortinget, Olje- og energidepartementet, Justis- og beredskapsdepartementet, UDI – Utlendingsdirektoratet, og SSB har mottatt innsynshenvendelser som fortsatt er ubesvarte). Gjennomsnittstiden her var et par uker (med unntak av de 12 tilfellene der det ikke har kommet noe svar). Det følger av offentlighetsloven § 29 første ledd at henvendelser om innsyn i forvaltningens dokumenter skal besvares «uten ugrunnet opphold», noe som ifølge Sivilombudsmannen i de fleste tilfeller skal fortolkes som «samme dag eller i alle fall i løpet av 1-3 virkedager». Så her er det rom for forbedring.

Klageretten (offentleglova § 32) ble benyttet i 20 av innsynshenvendelsene. I de fleste (15; 75%) av tilfellene førte klagen til at henvendelsen ble vellykket. Gjennomsnittstiden for å få svar på klagen var en måned (med unntak av 2 tillfeller, klager sendt til Statens vegvesen og Ruter AS, der det ikke har kommet noe svar). Det er vel verdt å klage, og helt gratis! Sivilombudsmannen har uttalt at 2-3 uker ligger over det som er akseptabel saksbehandlingstid for klager.

Flest henvendelser var blitt sendt til Utenriksdepartementet (9), tett etterfulgt av Fredrikstad kommune og Brønnøysundregistrene. I alt ble henvendelser sendt til 60 offentlige myndigheter, hvorav 27 ble tilsendt to eller flere. Det står over 3700 myndigheter i databasen til Mimes brønn. De fleste av dem har dermed til gode å motta en innsynshenvendelse via tjenesten.

Når vi ser på hva slags informasjon folk har bedt om, ser vi et bredt spekter av interesser; alt fra kommunens parkeringsplasser, reiseregninger der statens satser for overnatting er oversteget, korrespondanse om asylmottak og forhandlinger om toppdomenet .bv, til dokumenter om Myanmar.

Myndighetene gjør alle mulige slags ting. Noe av det gjøres dÃ¥rlig, noe gjør de bra. Jo mer vi finner ut om hvordan  myndighetene fungerer, jo større mulighet har vi til Ã¥ foreslÃ¥ forbedringer pÃ¥ det som fungerer dÃ¥rlig… og applaudere det som  bra.  Er det noe du vil ha innsyn i, sÃ¥ er det bare Ã¥ klikke pÃ¥ https://www.mimesbronn.no/ og sÃ¥ er du i gang 🙂

by Mimes Brønn atJuly 15, 2016 03:56 PM

June 01, 2016

Kevin Brubeck Unhammer

Maskinomsetjing vs NTNU-eksaminator

Twitter-brukaren @IngeborgSteine fekk nyleg ein del merksemd då ho tvitra eit bilete av nynorskutgåva av økonomieksamenen sin ved NTNU:

Dette var min økonomieksamen på "nynorsk". #nynorsk #noregsmållag #kvaialledagar https://t.co/RjCKSU2Fyg
Ingeborg Steine (@IngeborgSteine) May 30, 2016

Kreative nyvinningar som *kvisleis og alle dialektformene og arkaismane ville vore usannsynlege å få i ei maskinomsett utgåve, så då lurte eg på kor mykje betre/verre det hadde blitt om eksaminatoren rett og slett hadde brukt Apertium i staden? Ingeborg Steine var så hjelpsam at ho la ut bokmålsutgåva, så då får me prøva 🙂

NTNU-nob-nno.jpeg

Ingen kvisleis og fritt for tær og fyr, men det er heller ikkje perfekt: Visse ord manglar frå ordbøkene og får dermed feil bøying, teller blir tolka som substantiv, ein anna maskin har feil bøying på førsteordet (det mangla ein regel der) og at blir ein stad tolka som adverb (som fører til det forunderlege fragmentet det verta at anteke tilvarande). I tillegg blir språket gjenkjent som tatarisk av nettsida, så det var kanskje litt tung norsk? 🙂 Men desse feila er ikkje spesielt vanskelege å retta på – utviklingsutgåva av Apertium gir no:

NTNU-nob-nno-svn.jpeg

Det er enno eit par småting som kunne vore retta, men det er allereie betre enn dei fleste eksamenane eg fekk utdelt ved UiO …

by unhammer atJune 01, 2016 09:45 AM

October 18, 2015

Anders Nordby

Fighting spam with SpamAssassin, procmail and greylisting

On my private server we use a number of measures to stop and prevent spam from arriving in the users inboxes: - postgrey (greylisting) to delay arrival (hopefully block lists will be up to date in time to stop unwanted mail, also some senders do not retry) - SpamAssasin to block mails by scoring different aspects of the emails. Newer versions of it has URIBL (domain based, for links in the emails) in addtition to the tradional RBL (IP based) block lists. Which works better. I also created my own URIBL block list which you can use, dbl.fupp.net. - Procmail. For user on my server, I recommend this procmail rule: :0 * ^X-Spam-Status: Yes .crapbox/ It will sort emails that has a score indicating it is spam into mailbox "crapbox". - blocking unwanted and dangerous attachments, particularly for Windows users.

by Anders (noreply@blogger.com) atOctober 18, 2015 01:09 PM

April 14, 2015

NUUG events video archive

20111108_lisp

April 14, 2015 11:13 AM

January 06, 2015

thefastestwaytobreakamachine

NSA-proof SSH

ssh-pictureOne of the biggest takeaways from 31C3 and the most recent Snowden-leaked NSA documents is that a lot of SSH stuff is .. broken.

I’m not surprised, but then again I never am when it comes to this paranoia stuff. However, I do run a ton of SSH in production and know a lot of people that do. Are we all fucked? Well, almost, but not really.

Unfortunately most of what Stribika writes about the “Secure Secure Shell” doesn’t work for old production versions of SSH. The cliff notes for us real-world people, who will realistically be running SSH 5.9p1 for years is hidden in the bettercrypto.org repo.

Edit your /etc/ssh/sshd_config:


Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms diffie-hellman-group-exchange-sha256

sshh
Basically the nice and forward secure aes-*-gcm chacha20-poly1305 ciphers, the curve25519-sha256 Kex algorithm and Encrypt-Then-MAC message authentication modes are not available to those of us stuck in the early 2000s. That’s right, provably NSA-proof stuff not supported. Upgrading at this point makes sense.

Still, we can harden SSH, so go into /etc/ssh/moduli and delete all the moduli that have 5th column < 2048, and disable ECDSA host keys:

cd /etc/ssh
mkdir -p broken
mv moduli ssh_host_dsa_key* ssh_host_ecdsa_key* ssh_host_key* broken
awk '{ if ($5 > 2048){ print } }' broken/moduli > moduli
# create broken links to force SSH not to regenerate broken keys
ln -s ssh_host_ecdsa_key ssh_host_ecdsa_key
ln -s ssh_host_dsa_key ssh_host_dsa_key
ln -s ssh_host_key ssh_host_key

Your clients, which hopefully have more recent versions of SSH, could have the following settings in /etc/ssh/ssh_config or .ssh/config:

Host all-old-servers

    Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-ripemd160
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Note: Sadly, the -ctr ciphers do not provide forward security and hmac-ripemd160 isn’t the strongest MAC. But if you disable these, there are plenty of places you won’t be able to connect to. Upgrade your servers to get rid of these poor auth methods!

Handily, I have made a little script to do all this and more, which you can find in my Gone distribution.

There, done.

sshh obama

Updated Jan 6th to highlight the problems of not upgrading SSH.
Updated Jan 22nd to note CTR mode isn’t any worse.
Go learn about COMSEC if you didn’t get trolled by the title.

by kacper atJanuary 06, 2015 04:33 PM

December 08, 2014

thefastestwaytobreakamachine

sound sound

Intermission..

Recently I been doing some video editing.. less editing than tweaking my system tho.
If you want your jack output to speak with Kdenlive, a most excellent video editing suite,
and output audio in a nice way without choppyness and popping, which I promise you is not nice,
you’ll want to pipe it through pulseaudio because the alsa to jack stuff doesn’t do well with phonom, at least not on this convoluted setup.

Remember, to get that setup to work, ALSA pipes to jack with the pcm.jack { type jack .. thing, and remove the alsa to pulseaudio stupidity at /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf

So, once that’s in place, it won’t play even though Pulse found your Jack because your clients are defaulting out on some ALSA device… this is when you change /etc/pulse/client.conf and set default-sink = jack_out.

by kacper atDecember 08, 2014 12:18 AM

October 31, 2011

Anders Nordby

Taile wtmp-logg i 64-bit Linux med Perl?

Jeg liker å la ting skje hendelsesbasert, og har i den forbindelse lagd et script for å rsynce innhold etter opplasting med FTP. Jeg tailer da wtmp-loggen med Perl, og starter sync når brukeren er eller har blitt logget ut (kort idle timeout). Å taile wtmp i FreeBSD var noe jeg for lenge siden fant et fungerende eksempel på nettet:
$typedef = 'A8 A16 A16 L'; $sizeof = length pack($typedef, () ); while ( read(WTMP, $buffer, $sizeof) == $sizeof ) { ($line, $user, $host, $time) = unpack($typedef, $buffer); # Gjør hva du vil med disse verdiene her }
FreeBSD bruker altså bare verdiene line (ut_line), user (ut_name), host (ut_host) og time (ut_time), jfr. utmp.h. Linux (x64, hvem bryr seg om 32-bit?) derimot, lagrer en hel del mer i wtmp-loggen, og etter en del Googling, prøving/feiling og kikking i bits/utmp.h kom jeg frem til:
$typedef = "s x2 i A32 A4 A32 A256 s2 l i2 i4 A20"; $sizeof = length pack($typedef, () ); while ( read(WTMP, $buffer, $sizeof) == $sizeof ) { ($type, $pid, $line, $id, $user, $host, $term, $exit, $session, $sec, $usec, $addr, $unused) = unpack($typedef, $buffer); # Gjør hva du vil med disse verdiene her }
Som bare funker, flott altså. Da ser jeg i sanntid brukere som logger på og av, og kan ta handlinger basert på dette.

by Anders (noreply@blogger.com) atOctober 31, 2011 07:37 PM

A complete feed is available in any of your favourite syndication formats linked by the buttons below.

[RSS 1.0 Feed] [RSS 2.0 Feed] [Atom Feed] [FOAF Subscriptions] [OPML Subscriptions]

Subscriptions