So, I don’t do this often enough, but when I do, I forget how to do it EVERYTIME. The below allows a specific user access to a specific database from a remote connection.
UPDATE db SET host='FQDN' WHERE db='database_name';
UPDATE user SET host='FQDN' WHERE user='user_name';
FLUSH PRIVILEGES;
GRANT ALL PRIVILEGES ON database_name.* TO 'user_name'@'FQDN' IDENTIFIED BY 'the_password';
FQDN refers to the server that is making the connection to the database server.
On a properly secured system, sudo access should never be provided. Even if it is provided, one should avoid letting loose on the access. It’s best practice to only enable specific commands that enable the end user to complete their jobs. However, some battles cannot be won. So, let’s discuss removing access to certain items. We’ll do this using visudo.
Execute this command to get started:
visudo
The first thing we should do is specify a log where so we can quickly delineate the actions being taken by sudoers
Defaults logfile=/var/log/sudo.log
We then want to force sudoers into a headache and make sure they type in their password every single time.
Defaults timestamp_timeout=0
Now we want to make things easier on the eyes and create aliases so our later command is easier to look at quickly
Cmnd_Alias NVSU = /usr/sbin/visudo
Cmnd_Alias NSU = /bin/su
Cmnd_Alias NSHELLS = /bin/sh,/bin/bash
Cmnd_Alias NYUM = /usr/bin/yum
Cmnd_Alias NPASSWD = /usr/bin/passwd
And finally, we enforce our settings on the appropriate group of users that have sudo access:
%group_name ALL=(ALL) ALL, !NVSU, !NSU, !NSHELLS, !NYUM, !NPASSWD
The above line indicates that whomever is part of the group_name, can execute everything, as any user, and run all commands EXCEPT running visudo, su, sh, bash, passwd, and yum. We prevent the following from happening:
I know there is some more that should be added to this list. However, for my particular application, this was suitable.
visudo is very powerful and if not done properly it can break sudo or provide unintentional access. Do the research before you modify this configuration!
A sudoer still has the capability to compile or rpm a different shell. From which gets around this entire setup. Darn.
The above is for rpm based systems, Red Hat or CentOS. Modify accordingly for debian type OS’s.
Communication is very important in the business world. In working in the support desk, it can be frustrating when working with end users. Today I decided to send off an email to my team restating an issue that is being reported by a particular department. And I must say, I had fun writing this sentence:
They made note that there is a constant issue that continues to occur on a regular basis that is intermittent and sporadic.
I utilize an ironkey for the office and at some point in time I had to utilize a headless linux box for file transfers. However the linux box was missing some packages that are required to be unlock the iron key. In this case I’m utilizing a CentOS 6 x64 system. Here’s some additional packages that I needed in order to get the ironkey working appropriately:
glibc-2.12-1.107.el6.i686
libgcc-4.4.7-3.el6.i686
Hopefully that helps some people out there.
http://www.howtodoityourself.org/2012/05/04/how-to-fix-libld-linux-so-2-bad-elf-interpreter-no-such-file-or-directory.html
My error that I encountered:
[root@testcentos6 linux]# ./ironkey
-bash: ./ironkey: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
To troubleshoot:
[root@testcentos6 linux]# yum provides ld-linux.so.2
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: centos.mirror.constant.com
* centosplus: centos.mirror.nac.net
* contrib: mirror.teklinks.com
* extras: centos.mirror.constant.com
* updates: centos.mirror.nac.net
glibc-2.12-1.107.el6.i686 : The GNU libc libraries
Repo : base
Matched from:
Other : ld-linux.so.2
Then I had another issue:
[root@testcentos6 linux]# ./ironkey
./ironkey: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
So take two in troubleshooting:
[root@testcentos6 linux]# yum provides libgcc_s.so.1
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: centos.mirror.constant.com
* centosplus: centos.mirror.nac.net
* contrib: mirror.teklinks.com
* extras: centos.mirror.constant.com
* updates: centos.mirror.nac.net
libgcc-4.4.7-3.el6.i686 : GCC version 4.4 shared support library
Repo : base
Matched from:
Other : libgcc_s.so.1
Results!
[root@testcentos6 linux]# ./ironkey
Enter your IronKey password: ********
Unlock successful.
IronKey device names are cd: /dev/sr1 hdd: /dev/sda
2 ubuntu servers
Install puppet
apt-get install puppetmaster
Modify “DNS”
vim /etc/hosts
Modify the below (this is so the server knows who the client is):
127.0.0.1 localhost.localdomain localhost puppet
192.168.1.17 puppetclient.home puppetclient
Get my repo
cd /etc/puppet
git clone git@github.com:jtslear/bearded-octo-hipster.git
Restart puppet for good measure:
service puppetmaster restart
Ensure it starts appropriately, check log files, etc…
Install puppet
apt-get install puppet
Modify “DNS”
vim /etc/hosts
Insert the below (this is so the client knows who the server is):
192.168.1.16 puppetmaster.home puppetmaster puppet
Configure the service to start
vim /etc/default/puppet
Modify the below appropriately:
START=yes
Then start the service:
service puppet start
We need to accept the cert provided by the client, on the server:
sudo puppetca --sign puppetclient.home
On the client, let’s restart puppet, and wait for all to install:
service puppet restart
tail -f /var/log/syslog