Seis, Intel – palataan kesällä!

Reading Time: < 1 minute

Yksi ikävimmistä tavoista aloittaa päivä on huomata, että oma kone ei toimi.

Näillä ohjeilla pistät Intelin mikrokoodi epävakaat jakelut toistaiseksi paussille, apt-pohjaisissa Linuxeissa kuten Ubuntussa.

(Microsoft-laitteille tietoiskua Microsoftin sivulta)

Jos pääsiäisen 2018 tienoilla yhtäkkiä Ubuntu-tietokoneenesi tuntuu “hajoavan”, esimerkiksi näyttämällä kernel panic, tarkista ensin onko kyseessä vain huono ohjelmistopäivitys. Saatat selvitä turhan uuden laitteen ostamiselta, ja kaikelta muulta rumbalta mikä siihen monesti liittyy.

TL;DR: Jos haluat estää mikrokoodipäivityksen

  1. Avaa shelli
  2. sudo apt-mark hold intel-microcode
  3. Tarkista, että meni perille.
  4. Seuraa uutisia seuraavan 3-6 kk aikana aika-ajoin
  5. Kun intel-microcode paketti on alkanut stabiloitua ja kaatumisuutisia ei kuulu, voit ottaa päivitykset käyttöön:
    sudo apt-mark unhold intel-microcode

Tarkista hold ajamalla vielä yksi komento

Helppo tarkistaa, menikö hold perille:

$ apt-mark showhold
intel-microcode

Muista tarkistella aika ajoin miten asia kehittyy. Nyt toistaiseksi, jos pidät muuten koneesi tietoturvallisena, eli Linuxissasi ei ole potentiaalisesti tuntemattomia käyttäjiä sisällä, en näkisi ongelmatilanteen estämiseksi mikrokoodipäivitysten lykkäämistä huonona ideana.

Tasapainottelua: teoreettinen ongelma vai kaatunut kone?

Käsittääkseni kotikäytössä koko Meltdown-ongelma on varsin pieni. Meltdown sallii sivukanavaa pitkin tapahtuvan tiedon lukemisen; käytännössä monen käyttäjän servereissä kernelin muistisuojaus pettää, koska modernien prosessorien cachet ja predictive branching sallii käytännössä prosessille tilaisuuden vakoilla limittäin tapahtuvan laskennan tuloksia niiden jättämien jälkien (“sivuvaikutusten”) perusteella.

N&Bx: dissecting bash, 2: environment

Reading Time: 2 minutes

Hi, and this is the second blog in the series Nuts&Bolts with Linux, or ‘N&Bx’.

I use bash daily at home and work, and thought of writing a bit of introduction to this “swiss army knife of CLI”. Bash comes in the line of Unix shells, and it has some of the principles and roots in the

Bash and its environment

Bash, the fine shell that is readily available for a wide range of operating systems, was introduced in the first part.

We’ll go further into the dungeons, and focus on how a bash shell session gets its environment set up.

The system-wide file for all bash instances is:

/etc/profile

AND then additionally

~/.bash_profile (if this exists), OR
~/.bash_login (is this exists), OR finally
~/.profile

bash reads and executes commands from the first such config file (of the above 3) that exists and is readable (user has +r right over the file).

Last setting “rules” (over previous ones)

Sometimes the various profile files might have settings that affect the same variable. In that case, the last of those settings will prevail. Unless the profile’s setting is written such that it takes previous settings into account; typical example is PATH variable setting with:

export PATH="$PATH:/usr/newpath"

“The new PATH shall be the current PATH, appended with string :/usr/newpath”

Is the ‘export’ necessary?

In a word, yes. Without an export, the assignment would only be scoped within the execution of the profile script – not your shell session. You can easily try out the difference.

set | less

..and you can explore the current environment variables — use space for paging, or ‘q’ to quit immediately.

Switches to bash for overriding defaults

Bash, as a program, is hardwired to read certain configurations when it starts. However, as is good practice, these can be overridden with command line switches. The switches are passed to bash (more about this later in the article).

Here’s 2 useful switches:

–noprofile

A ‘–noprofile’ option tells bash to not read /etc/profile or any other of the 3 default profile definition files. Still, with ‘–noprofile’ provided, the bash will read its rc configuration files. See below for how to prevent those.

Unless, the rc configuration is prevented with:

--norc

A –norc tells bash not to read:
~/.bashrc

Why /etc/profile and rc files?

The ‘.bashrc’ is a configuration file, whereas ‘profile’ files are more geared towards user’s preferences. I’m by far not an authoritative monk in this, but I’d put technical settings that affect the behavior of bash itself into ‘.bashrc’, while all kinds of things that really affects in a tangible manner the environment into ‘profiles’.

N&Bx: dissecting (ba)sh

Reading Time: 2 minutes

Welcome to Nuts&Bolts with Linux, or ‘N&Bx’.

I’ll keep sharing some of the things that have recently found. It’s amazing how rich a GNU/Linux system actually is. I’ve jokingly said many times that you can either play games, or just explore more and more of a Linux. Either way you won’t run out of things to do.

What is a shell?

The shell is really what it says; kind of cover, an enclosing; “world of its own”. The shell’s purpose is to interpret commands and act as a middleman between users and the core of the operating system. Without a shell we’d be really hardcore enthusiasts, like those of the 1950s who knew how to program a computer by switching levers and knobs on and off.

There are mainly 3 kinds of shell usage

The most usual that we think of with a shell is interactive use: you type commands, and the shell is your tool to speaking with underlying OS. A shell can contain a lot of amenities and amendments that we take for granted, and some that are probably still undiscovered by many users.

Second kind of usage is executing a single command with a shell. You’ve probably seen those

sh -c "echo '1' >> file"

kind of commands that take advantage of the shell’s rich internal commands, pipes, and combine these sometimes with program execution.

Third use case is where a script uses a shell as an executing environment. This is the batch mode; for example in Linux, the commands that regularly run via scheduling, take a shell underlying, which sets a execution environment, and then the payload command runs on top of that. The payload itself can be a shell script, internal shell command or an external binary (program).

Bash had been my default shell in Linux for years. I had not even thought the decision originally as to ‘why’, but I guess bash seemed somewhat more sophisticated than the standard ‘sh’ shell.

Next in N&Bx we’ll check out how does bash set up the “environment” and its own options. Until then, adios!