Having recently come to light, meltdown and spectre are names given to a set of high impact security issues exploiting CPU instructions to read system memory. Provided below is a collection of links that relate to different aspects of these vulnerabilities.
Updates from Vendors
- KPTI: https://lwn.net/Articles/741878/
- PCID (to lessen the performance impact of KPTI): http://archive.is/ma8Iw
- Retpoline: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
- Intel Microcode update: https://news.ycombinator.com/item?id=16111433
Performance / Benchmarks
Bits from the web
To quote Wikipedia,
A roaming user profile is a concept in the Windows NT family of operating systems that allows users with a computer joined to a Windows Server domain to log on to any computer on the same network and access their documents and have a consistent desktop experience, such as applications remembering toolbar positions and preferences, or the desktop appearance staying the same.
Our office environment consists of a mix of Windows and Linux systems. The task was to setup a system on which user data could be stored, such that the users would not be bound to a single system, and be able to work from any system.
- [server side] Samba can be used to setup a Domain controller to authenticate users (for Linux only environments, solutions like Free IPA also exist).
- [client side] Can be setup by combining different services (as given here and here), or an integrated system can be used (like given here).
After considering the above, we went with the following solution:
Server side setup
Went with Zentyal server for user authentication, data storage, and file sharing (other options like ClearOS also exist).
Client side setup
Used pbis open for authenticating to the AD server, and put together a system for implementing roaming profiles.
Roaming profile setup
When searching for roaming profile on linux, csync was found which seemed like the ideal solution; however in practice an issue was encountered trying to sync between a local home folder and a samba mount of the remote folder.
Eventually discovered osync which synced the folders (local and remote) correctly.
Wrote some scripts tie it all together (available here).
Hi there folks!
This time we are going to talk about something different: using Gitlab and its CI system for deployments.
Gitlab CE (community edition) is an Open Source git platform that can be used to host your git repositories on a server. It offers most of the features offered by Github, with the advantage that you can host it on your own server.
In my previous organization we were using Github for hosting our git repos and using git along with git hooks for deployment on the server (tutorial). Now with a bigger team we needed a pull request and merge based approach with deployments for the same. After evaluating the options available, my thoughts are as follows:
1. Custom Hooks
These are basically git’s server side hooks and only run when someone pushes to the repo.
- Easy to setup, supported by git, and documented.
- Not executed on merges.
- Difficult to redeploy.
These allow hitting a URL for certain actions / events like push, merge, etc.
- Easy to understand.
- Triggered on both pushes and merges.
- Need to setup a custom webhook handler for it on the deployment server.
- Since Gitlab’s webhook system does not allow to store any state (like whether the deployment succeeded, or is in progress), this information needs to be stored by the webhook handler on the server (I find Github’s webhook system much better in this regard).
3. Gitlab CI
This is Gitlab’s CI (Continuous Integration) and CD (Continuous Deployment) system.
- Quite featureful and customizable.
- Runs on both pushes and merges.
- Can be used to track deployment status and redeploy if needed.
- Higher learning curve.
Gitlab CI system looks like the more appropriate choice as per the requirements. Only thing now is to set it up.
Setting up the Gitlab Runner
Gitlab Runner is what we will be installing on the deployment server. Installation is simple but there is a question: which executor to use? Since we are deploying on the same server as the runner (and not doing anything else that needs a clean environment), we will be choosing the shell executor.
Whenever there is a commit in the Gitlab repo, the runner gets notified, places us in a checkout of the commit, and runs through what is specified in .gitlab-ci.yml (for example I wrote a bash script to transfer the changed files using rsync to a location in the docroot of the webserver).
Here is a sample project which can deploy to a location on push (and remove the deployment if the source branch is deleted): gitlab-ci-sample.
And that’s it! Let me know in the comments if there are any questions.
I have not used it myself, but Auto DevOps looks cool too.
For deploying on live I found the following link helpful: https://florianbrinkmann.com/en/3473/deployment-gitlab-ci/
By default gitlab runner is installed and run as a service using the root user, while running jobs as a non-root user (gitlab-runner).
More info: [link]
For setups like shared hosting root access is not available. So we can do it the following way:
1. Setup gitlab runner
gitlab-runner needs to be downloaded and registered with a gitlab account/project.
After registering it can be started using the run_gitlab_runner.sh script.
It can be monitored and kept running using monit (detailed below).
2. Setup monit to monitor gitlab runner
monit is used to monitor gitlab runner and restart it in case it fails.
It can be run using the run_monit.sh script. Before running monit .monitrc file would need to be setup (template provided).
Note- Files and instructions referenced above are available at gitlab-runner-as-normal-user.
Additionally, to ensure monit itself is running and kept running even on restart, it can be added to cron:
/home/youruser/scripts/run_monit.sh >> /home/youruser/logs/cron-service.log
Have been using this setup on multiple accounts for a few weeks now, running as expected! 🙂
Since I intended to compile software on the Pi, I looked into external cooling solutions and found that adding a heat sink and fan should work. Ordered the items, and when they came I attached them to the Pi.
But there was an issue: the fan was too loud and not really required unless the Pi was heating.
Searching for solutions, I found two tutorials, the first of which used a transistor controlled via the Raspberry Pi’s GPIO system (I could not find the suitable transistor online) to turn the fan on/off as required, and the second one which used a relay module (which I could find online and ordered).
After some fiddling around, managed to get the connections right, and it worked! There was a strange issue though that whenever the GPIO pin was set to output mode, irrespective of the fact whether the voltage was HIGH or LOW, the fan got switched on. As a workaround I set the GPIO pin to input mode instead of setting it to output LOW and it worked.
I took the scripts from the tutorials , modified them a bit to workaround the above issue, merged the best bits, and wrote some code for monitoring. All this is now available in a Github repo.
If anyone has any comments or queries feel free to post them in the comments section below.
While waiting for Manjaro 17.0 to be released, have created RC ISOs for Manjaro OpenRC 17.0 Xfce edition.
- Kernel updated to 4.9.x series (next LTS).
- Reverted to using ALSA by default (decided by voting, see here for reference).
- Old CLI installer patched to work with manjaro-tools 0.13.8 (changes
P.S. May also create Net Edition ISOs this time around if there is need for them.
RC (Release Candidate) ISOs were released, have updated the download link (old link for reference).
After about a month of development (mostly over the weekends), Manjaro OpenRC 16.10.2 ISO has been released. It was originally not intended as a development edition, but become one since I noticed that it failed to boot in EFI mode both in Virtualbox as well as on bare metal,
and was unable to fix it (has been fixed).
Major changes are the inclusion of Linux 4.8 to better support newer hardware like AMD Polaris, and the inclusion of Pulseaudio for better out of the box support for multiple audio devices (more of that in the release announcement).
Minor changes include switching the icon theme to elementary-xfce-icons (shoutout to oberon2007 for adding it to the community packages), and adding hardinfo for graphical system information, and ffmpegthumbnailer for video thumbnails.
Release announcement: https://forum.manjaro.org/t/manjaro-openrc-16-10-2-iso/13654