Xubuntu 14.04 Samba setup for access by ubuntu and windows clients

Xubuntu 14.04 Samba setup for access by ubuntu and windows clients

Setting up a samba server locally was done as follows on ubuntu 14.04. On the server I had some errors with missing dependencies and had to perform some purges on samba packages to resolve them.

Reading this, this and this  helped.

Samba Server setup  

On the samba server, run the following:

sudo apt-get install samba samba-common system-config-samba gksu

I received errors that certain samba package dependencies could not be met, and searching for a fix led me to do this:

sudo apt-get clean
sudo apt-get autoremove
sudo apt-get update
sudo apt-get upgrade
sudo apt-get purge samba-common
sudo apt-get purge samba-libs

On xubuntu, could not find the samba config GUI from the menu, turns out I had to run it like this:

gksu system-config-samba

At this point in time I configured the share and user. 

Samba Client (linux)

On the first client, an ubuntu machine, I ran the following to get configured

sudo apt-get install samba cifs-utils

Create a credentials file so that the user and password is not littered everywhere

sudo nano /etc/samba/user

Add these:

username=samba_user
password=samba_user_password 

Set permissions to ro:

sudo chmod 0400 /etc/samba/user

Then edit /etc/fstab, add this entry as a new line to mount on boot:

sudo cp /etc/fstab /etc/fstab.bak1
sudo /etc/fstab

Add this line:

//samba-server/share  /media/share  cifs  credentials=/etc/samba/user,noexec  0 0

Either reboot or mount and you should be in:

sudo mount /media/share/

Samba Client (Windows)

Easy really, just open explorer and go to the network share \\samba-server\share\, enter the samba user and password and you're in.

@quintes

finding the docker mount volume location - running jenkins in a container

Finding the Docker mount volume location, running Jenkins in a container

I love running jenkins in a container, no installation locally, and it really is awesome to just spin up a docker container image and run a build process.

I had setup a jenkins container around 5 months ago running on docker and forgot the password and the path to the mounted volume. Here's how you go about getting the volume so you can reset the password

Locate the volume  

I configured my jenkins to use a mounted volume, and had no idea where it was. This is a lazy manner of getting the path - it will be under the mount section:

docker inspect my-jenkins | grep "Source"

Update: this is the proper way to get the mount source:

docker inspect --format='{{range .Mounts}}{{ .Source}}{{end}}'

and locate the folder locally, mine was at
/var/lib/docker/volumes/e6bc1cd088645a4f5b7f69c0ba00951b159b0ccf552cf02bd31c85d64cb35626/_data

Now that I have the mount path I can change the security attribute to false, log in and configure the security again, but at least I am back in.

Docker makes playing with software in images simple; in this way even though I have java installed locally I don't need to spin up and keep jenkins running all the time, just when I want to spin it up.

Cheers

Quintes

Connect with me on LinkedIn or Twitter

Xubuntu 14.04.x Hardware Enablement Stack (HWE) EOL and disappearing mouse cursor

Xubuntu 14.04.x Hardware Enablement Stack (HWE) EOL and disappearing mouse cursor

It may surprise many people but I run Linux at home. I actually ran CentOS for a number of years as a desktop / server and then moved to Xubuntu around 2009, and have 2 laptops running it in various versions and flavours since. Let me start this by saying I heart xubuntu.

Around a month and a half ago I received a popup in Xubuntu 14.04 stating that my HWE stack was going to stop receiving updates for the kernel and graphics stack. A wiki article stated it should be fine to update to the xenial stack. Sounds critical and I responded with enough due diligence to believe my primary home laptop would upgrade fine.. in the process my intel video drivers got groggy and would cause the mouse cursor to disappear whenever (every time) I returned from sleep / a locked screen.

Pre-HWE EOL  

I've been running Xubuntu 14.04 x64 as a my primary machine for a long while. Developer tools, docker, java, lamp, virtual boxes etc. Intel video. Nothing fancy.
  

I upgraded after reading through the mentioned article and getting the warnings as expected

 sudo lsb_release -d
 hwe-support-status --show-replacements
 hwe-support-status --show-all-unsupported

I was running the relevant kernel, followed the steps to upgrade, not reinstall from scratch. My machine kept going but noticed that my cursor would disappear when unlocking from the light locker. I was kinda busy and didn't want to fix so found the common fix which is change from vt1 to vt7. 

I wish I'd taken more notes, but appears that I was bumped from a 3.13 to a 4.2 Kernel. I think I was somewhere refered to this and installed everything as per the 14.04 Desktop step. 

Now what's worse is that I had taken the other machine last week and performed a fresh install of Xubuntu 14.04.5 on it and this happens. New install or upgrade, same issue. In that instance I went and re-installed Xubuntu 14.04.1 and my cursor comes back as I'd expect so it's a new bug.

Getting my cursor back

Today I traced through a couple of articles and bug trackers and found that I was not alone. Note that this is still happening in xubuntu 16.04 which mentions the following under known issues on the release notes page, as at this date - "When returning from lock, the cursor disappears on the desktop, you can bring the cursor back with Ctrl+Alt+F1 followed by Ctrl+Alt+F7"

Now I want my wife to use my laptop for a specific purpose under a standard desktop users - can you image that discussion with someone who doesn't use linux or worse is not used to 30 keyboard shortcuts after a login. A poor, annoying workaround kept me going but not suitable.

Where else is this happening? 

Here. Every other workaround there is great, if you don't have to explain it.

Note I'd tried restarting lightdm, it kills your workspace and not suitable. Installing gdm? I gave that a spin earlier, do not do it. It killed my notifications bar, panel shortcuts etc. 

I quickly uninstalled gdm and purged/reinstalled light-locker. 

  sudo apt-get remove gdm
  sudo apt-get remove light-locker
  sudo apt-get purge light-locker
  sudo apt-get install light-locker

Man is it pretty in comparison. My Indicator plugins and panels loaded properly as I hoped too.

Ubuntu Bug Ticket - same workarounds mentioned and I noted that it was fixed in xserver-xorg-video-intel in Xenial. 

So I thought I'd just upgrade that since I'd installed the Xenial packages as per the HWE EOL wiki. 

sudo apt-get install xserver-xorg-video*

When I tried I saw that some dependencies would not be met. So I tried to reinstall all of it 

sudo apt-get install --install-recommends linux-generic-lts-xenial xserver-xorg-core-lts-xenial xserver-xorg-lts-xenial xserver-xorg-video-all-lts-xenial xserver-xorg-input-all-lts-xenial libwayland-egl1-mesa-lts-xenial 

I shouldn't have done this, because I got a new 4.4.0.59 kernel and then my /boot proceed to run out of space - fixed that and retried. All appeared OK and I tried to lock and unlock - cursor continued to disappear.

I then decided to reboot and try after that. Kernel panic ensued and thankfully my 3.13 kernel was still available. So I booted with the 3.13 kernel, and by then was pretty mad. I forced trusty back

sudo apt-get install --install-recommends linux-generic-lts-trusty xserver-xorg-core-lts-trusty xserver-xorg-lts-trusty xserver-xorg-video-all-lts-trusty xserver-xorg-input-all-lts-trusty libwayland-egl1-mesa-lts-trusty

sudo dpkg-reconfigure linux-generic-lts-trusty

 After that I changed my grub config to use the old 3.13 kernel as default and had to hack the defaults to not use the 4.4 Kernel

sudo nano /etc/default/grub
GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 3.13.0-107-generic"
sudo update-grub

Rebooted, logged in and out and surprise - my mouse cursor is back.

Of course checking the HWE I seem to be covered but I'm sure I've broken something, and an apt-get update later will probably bring some pain.

hwe-support-status --verbose
Your Hardware Enablement Stack (HWE) is supported until April 2019.

This issue actually shouldn't be happening, in my opinion those release notes and ticket should be resolved by now. The lesson here is always test upgrades somewhere else before you play on your primary machine.

@quintes

Configure Redis Sentinels on ubuntu

Configure Redis Sentinel on ubuntu

I did this a long time back and this post details how it is done. I don't want to forget again. This is all done using localhost for simplicity on my laptop.

Install Redis

Install redis as necessary. Digital Ocean has a super article on the steps to follow.

Configure Sentinel

I created a github repo containing most of the config and bash scripts. Grab that and run it as follows

The idea is as follows:

Master Redis running port 6379 and a sentinel 23679

Slave 1 running port 6380 and sentinel 23680

Slave 2 running port 6381 and sentinel 23681

Run the Master

  redis-server $PWD/master/master-redis.conf

Test
  redis-cli -p 6379
  set bob 123
  get bob

Run the main sentinel

  redis-server $PWD/master/sentinel.conf --sentinel

  you will see the sentinel monitor
        +monitor master redis-local-cluster 127.0.0.1 6379 quorum 2

Run Slave 1

  redis-server $PWD/slave1/s1-redis.conf
  We can tell it is a slave:
        MASTER <-> SLAVE sync: Finished with success

Run Slave 1 Sentinel

 redis-server $PWD/slave1/s1-sentinel.conf --sentinel

 Connecting and working
        +monitor master redis-local-cluster 127.0.0.1 6379 quorum 2

Run Slave 2

 redis-server $PWD/slave2/s2-redis.conf

 Connecting and working
      MASTER <-> SLAVE sync: Finished with success

Run Slave 2 Sentinel

 redis-server $PWD/slave2/s2-sentinel.conf --sentinel

 Connecting and working
        +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ redis-local-cluster 127.0.0.1 6379
        +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ redis-local-cluster 127.0.0.1 6379
        +sentinel sentinel 01105752f94e78d38cab212f30a53ad139e09979 127.0.0.1 26379 @ redis-local-cluster 127.0.0.1 6379
        +sentinel sentinel 9348999cde7c3aa05dda31746e95f0fb964e1055 127.0.0.1 26380 @ redis-local-cluster 127.0.0.1 6379

Test using the redis-cli

  Connect to the main sentinel:

  redis-cli -p 26379
  127.0.0.1:26379> INFO [section]

  Returns:
    # Sentinel
    sentinel_masters:1
    sentinel_tilt:0
    sentinel_running_scripts:0
    sentinel_scripts_queue_length:0
    sentinel_simulate_failure_flags:0
    master0:name=redis-local-cluster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

  Figure out who is the master, asking slave 2
    redis-cli -p 26381 sentinel get-master-addr-by-name redis-local-cluster
  Returns, as expected:
    1) "127.0.0.1"
    2) "6379"

Test the slaves, ensure slaves are syncing
  Connect to the master redis

  redis-cli -p 6379
    127.0.0.1:6379> set mykey 123
    OK

  disconnect and connect to the first slave:

  redis-cli -p 6380
    127.0.0.1:6380> get mykey
    "123"
    127.0.0.1:6380>

Test the failover

  Kill the instance of redis which was started first

  Taking a look at the first sentinel output, we can see the redis instance went down
  Directly thereafter they all agreed on who to make the master

    +sdown master redis-local-cluster 127.0.0.1 6379
    +new-epoch 2
    +vote-for-leader 96f6cfd4193108b326fb15d1adbfb2ecc630ff97 2
    +config-update-from sentinel 96f6cfd4193108b326fb15d1adbfb2ecc630ff97 127.0.0.1 26381 @ redis-local-cluster 127.0.0.1 6379
    +switch-master redis-local-cluster 127.0.0.1 6379 127.0.0.1 6381

  The new master is on port 6381, lets try connect
  First check who the sentinel thinks is the master, ask either of the slave sentinels:

  redis-cli -p 26380 sentinel get-master-addr-by-name redis-local-cluster
    1) "127.0.0.1"
    2) "6381"

  Agreement, so lets see if we can set a key on what was previously a slave:

  redis-cli -p 6381
    127.0.0.1:6381> get mykey
    "123"
    127.0.0.1:6381> set mykey newhere
    OK

  Did it sync to 6380?
  redis-cli -p 6380
    127.0.0.1:6380> get mykey
    "newhere"
    127.0.0.1:6380>

  Performing an INFO on the main sentinel (which actually could've gone down too ) indicates that it too knows who is the new master
    # Sentinel
      sentinel_masters:1
      sentinel_tilt:0
      sentinel_running_scripts:0
      sentinel_scripts_queue_length:0
      sentinel_simulate_failure_flags:0
      master0:name=redis-local-cluster,status=ok,address=127.0.0.1:6381,slaves=2,sentinels=3

All good.

Summary

This hopefully gets anyone else up and running quickly

@quintes