After hosting the blog on own server for around 3 years now, back to wordpress.com for simplicity and economy.
This site will likely be deprecated in a couple of months, new link for the blog is abchk1234.wordpress.com/
Thanks for your support 🙂
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.
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.
After considering the above, we went with the following solution:
Went with Zentyal server for user authentication, data storage, and file sharing (other options like ClearOS also exist).
Used pbis open for authenticating to the AD server, and put together a system for implementing roaming profiles.
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:
These are basically git’s server side hooks and only run when someone pushes to the repo.
These allow hitting a URL for certain actions / events like push, merge, etc.
This is Gitlab’s CI (Continuous Integration) and CD (Continuous Deployment) system.
Gitlab CI system looks like the more appropriate choice as per the requirements. Only thing now is to set it up.
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.
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
Has been a nice ride so far 🙂
Finally got around to setting up a new blog.
Its available at https://abchk.in/
Lets see how long I keep posting 🙂
Trust in this brand eroded and I will likely never buy their phones again.