Gitlab Runner Error: sudo: no tty present and no askpass program specified

  • 0

Gitlab Runner Error: sudo: no tty present and no askpass program specified

Get Social!

After issuing the first build on a dynamically created Container I came across the following build error when running a command with sudo.

The error is caused by trying to run a command with sudo, however the calling user has not been authorised to use sudo. The error isn’t helpful, and doesn’t really spell out where to go, but adding the calling user to the sudoers file will save the day.

Solution

Open up the sudoers file for editing in your favorite editor.

And add your gitlab runner user to the bottom. If you installed your gitlab runner from the official apt repositories then your gitlab-runner process will run under the gitlab-runner user.

Add the following to the bottom of the file:

Retry your build and you should be back in business!

 


  • 0

GlusterFS Error cannot open /dev/fuse

Category : How-to

Get Social!

After installing glusterfs-client on my Debian server I received the below error when trying to mount a remote GlusterFS volume. The error indicates that the device at /dev/fuse cannot be found, however ls showed that it was available.

This was the error displayed in the Gluster log after running the mount command:

A quick check of the kernel fuse module using modprobe gave an error:

And some Googleing indicated that it’s because fuse-utils was missing. In my case it wasn’t.

Further investigation showed that the kernel had recently been updated, but the machine hadn’t been restarted so the latest installed kernel wasn’t the kernel that was running. There seemed to be some kind of mismatch between the loaded kernel and the fuse library.

A reboot of the machine fixed the issue – the fuse module loaded correctly and the Gluster mount executed without error.


  • 0

GlusterFS Error volume add-brick: failed: Pre Validation failed on BRICK is already part of a volume

Category : How-to

Get Social!

I received the below error today after I tried to add a ‘new’ brick to a GlusterFS volume. I’ve put the word ‘new’ into quotes because although the brick was new to the GlusterFS volume, the disk being added had been used as a brick before. The disk had all data removed from it, however somehow GlusterFS knew that the disk held some remnants of the previous brick.

The following command failed, trying to add the new brick:

The error received:

Solution!

The solution is to use setfattr to clear the hidden filesystem attributes containing GlusterFS information about the bricks previous life. Run the following commands on the server that has the drive that you’re trying to add as a new brick.

Of course, you should also ensure that the filesystem you’re adding is cleared, especially the .glusterfs hidden directory.

And that’s it! Try running the add-brick command again, and you should be in business.


  • 0

GlusterFS Mount failed. Please check the log file for more details.

Category : How-to

Get Social!

gluster-orange-antYou may get the following error when trying to mount a GlusterFS volume locally. The error displayed gives no indication why the volume failed to mount, but it does hint at where you can get more information about the error.

This is the error presented when running the mount command:

The log file could be in numerous places, depending on your Linux distribution and Gluster settings, however generally it will be in /var/log/glusterfs.

Take a look at the log file for further information on why the volume cannot be mounted. An example is included below, showing an issue with the fuse kernel module.

Your issue could vary, and as such we can’t cover every eventuality here. At least you now know how to get more details around your specific issue.


  • 1

Nginx Error “client intended to send too large body”

Category : How-to

Get Social!

nginx-logoYou may see the below error in your Nginx web server log files, and the good news is it’s easy to fix!

The error is presented because a request being sent to the server contains more data than Nginx allows by default. You can increase the allowed maximum with the client_max_body_size attribute.

You can add the client_max_body_size attribute to your configuration files in multiple places to control what sites or locations the attribute affects.  For example, you can add it to your main config file to ensure than any site can upload the value you set. The below example sets a global value of 50MB for all sites.

You could also add it inside the server { tags of an individual site, or even the location { tags of a specific location.

Once you have made your change remember to reload the configuration and the changes will take effect.