2014-06-26

automirror - Automate Linux Screen Mirroring


I do a lot of pair working and many times I connect a large TV or projector to my laptop for others to see what I am doing.

Unfortunately the display resolution of my laptop never matches that of the other display, and Linux tends to choose 1024x768 as the highest compatible resolution. This is of course totally useless for doing any real work.

My preferred solution for this problem is to use X scaling to bridge the resolution gap between the different screens.

Since none of the regular display configuration tools support scaling, I ended up typing this line very often:

xrandr --output LVDS1 --mode 1600x900 --output HDMI3 --mode 1920x1080 --scale-from 1600x900

Eventually I got fed up and decided to automate the process, the result is automirror, a little Bash script that automatically configures all attached displays in a mirror configuration. automirror is available on https://github.com/schlomo/automirror.

Typical Use Cases

Connecting a Full HD 1920x1080 display via HDMI to my 1600x900 laptop. In this case automirror will simply configure the HDMI device with 1920x1080 and scale the 1600x900 laptop display. As a result I stay with the full resolution on my laptop display and it also looks nice on the projector.

Another case is where I work with a 1920x1200 computer monitor and add the 1920x1080 projector as a second display. Again the common resolution offered by both devices is 1024x768. automirror will recognize my 1920x1200 display as primary display and scale it to 1920x1080 on the secondary display, which is not really noticeable.

It is recommended to configure a hot key to run automirror so that one can run it even if the display configuration is heavily mwessed up. In rare cases it might be neccessary to run automirror more than once so that xrandr will configure the displays correctly.

2014-06-20

Granting root access in a DevOps world

At the 2014-06 Berlin DevOps Meetup this week we had an interesting fish bowl discussion about

What is the risk of giving DEVs root access in production?

Since I suggested the topic I was asked to give a short introduction into the topic:


The discussion that followed was suprising in several aspects:
  • A major concern is safeguarding the production data, but nobody had a really good solution for that. Many people have more problems with Developers seeing live customer data than with Develops changing something in production.
  • "Nobody should have root" was proposed by a security specialist, but he had no practical working example for this approach.
  • The question is tightly coupled to the degree of automation. The more automation you have the less need for anybody (Dev or Ops) to use their root privileges.
  • Not everybody having root access knows what to do with it, Developers are sometimes afraid of using their power if granted root.
  • This is mostly a question for larger companies and classical IT organizations. Small companies and start ups just give root to everybody who knows what to do.
For me that was the first time having this discussion when nobody tried to prove that Developers should in principle not get root access. The Test Driven Infrastructure fish bowl at the Berlin DevOps Meetup 2013-12 last year also touched upon this topic and the discussion was much more against giving root access to Developers.

My personal opinion is that in a DevOps world people are in the focus of our interest. The official title or organizational position should matter less than what the people are doing. We should therefore
give root access to people based on
  • Trust to act in our common interest
  • Commitment to fix everything they brake
  • Skills to tread carefully in our production environment

2014-06-13

My SMART TV - Linux For The Win

I love my "smart" TV - it got Linux inside which is the base for a whole range of nice hacks.

TV Router

The most important one is that the TV is actually a wireless router that provides Internet via Ethernet to my TV rack. Usually the Ethernet connection is used by the Playstation or a Raspberry Pi.
The original reason for this hack was simple: The Playstation 3 has a really really bad Wifi reception which made watching Netflix nearly impossible and the unavoidable PS3 updates painfully long. The USB Wifi adapter connected to the TV has a much better reception, sharing it with the PS3 solved all the performance problems.

Samsung Linux TV

And here comes the good part. The TV (Samsung LE32C650) runs Linux inside and there is an Open Source project (SamyGO) that "opens up" the TV firmware and extends this Linux with useful tools.

In my case I only had to enable IP forwarding, configure a static IP on the Ethernet interface (eth0) and start a DHCP server on it. The Samsung kernel already included IP forwarding (thanks!) and the DHCP server is part of Busybox that comes with SamyGO.

NFS

Another benefit from rooting the TV is the option to add NFS support. The TV has a great media player that plays almost all file formats, even with subtitles and multiple audio tracks. The player can fast forward/rewind and even remembers the last playback position for each video. But all of these nice features only work when playing videos from USB storage, not over DLNA.

Thanks to SamyGO it is possible to mount a NFS share onto a directory on a USB stick. The TV thinks that the NFS share is on the USB stick and happily plays all the videos with all the fancy features.

Wife Acceptance Factor

Back in 2010, when I bought the TV, this was a really cool solution with a high WAF because both watching TV and videos from our collection work with the same remote control. Nowadays I would probably just attach a Raspberry Pi (with OpenELEC) to the TV and enjoy the seamless integration thanks to HDMI CEC. But is is still nice to know that I can extend my TV to better serve our needs.

I can only hope that the next TV will be equally hack friendly.