In my work I'm often in situation where I want to restart remote server, and then immediately connect to it over ssh.
This can be done by repeating ssh HOST in shell, but it gets tedious.
In my work I'm often in situation where I want to restart remote server, and then immediately connect to it over ssh.
This can be done by repeating ssh HOST in shell, but it gets tedious.
Today, I released new version of OmniPITR – 0.5.0.
This new version has one important new feature – which is so called “direct destination" for backups.
What it means? What it does? How it helps? Let's see…
At home I have couple of machines, but one of them takes relatively long time to login to.
It looks like this:
=$ time ssh blob id -u 1000 real 0m0.401s user 0m0.010s sys 0m0.000s
While 0.4s is not very long, it bugged me. And today, I decided to look into it, to see what's happening.
I had today a very weird situation.
From my laptop, I ssh to another system, and from there to yet another.
On this final system I noticed that vim starts relatively slow. i.e. this command:
time vim -u /dev/null -c “:q"
returned time in around 3.5 seconds, while on my laptop (which is much less powerful) it is:
=> time vim -u /dev/null -c ":q" real 0m0.073s user 0m0.056s sys 0m0.016s
I tried to debug the situation, and it got weirder. If I did “su – another_user" (on the final system) – it became fast. What's more: if I did su – depesz (my account) back – vim was still fast!
After some debugging it occurred to me: I have automatic X11 forwarding turned on. I checked – and yes, in the shell that vim starts slowly, i had “DISPLAY" variable, set to localhost:10.0!
Quick unset DISPLAY, and suddenly vim starts 0.027s!
Lesson for future – do not use automatic X11 forwarding for long-distance ssh connections, or make sure you run vim with “-X" option.
Later I learned why it tries X11 connection – to get access to X copy/paste buffer (available as * register). Nice feature, but with quite problematic side effects.
there is this situation: multiple people have to have access to single system account on unix/linux.
you are one of them, but you really want to have your own environment. aliases, path, and so on.
problem? others dont want your changes. is it a lost case?
Continue reading using separate environments for people using single account