Initial investigation...

1. to perform the install including postConfigure, I left things set to full sudo access.
2. Then I tried just doing a shutdown, stop, startsystem and made sure the OAm functionality was working. nobody was complaining about any sudo error, I STILL had to have this specific commands setup to allow sudo access:

Cmnd_Alias DB = /usr/sbin/fuser , /bin/chmod , /usr/sbin/lsof , /bin/chown , /bin/mount , /bin/systemctl , /bin/grep , /bin/echo , /usr/sbin/service , /bin/touch , /bin/pkill , /bin/rm , /bin/mkdir , /usr/sbin/sysctl

So this means at a minimum with NO code changes, we need sudo access to allow oam processes, scripts, and APIs to call these commands.

To allow things to work without any sudo access, code changes would need to be made and the Unix command list above would need to be replaced with some other C++ API command. Which I dont know if any or all are doable by the API.

Yes, what i was thinking is can we can look at the specific cases for shutdown / startup and see if there are alternatives including not doing these calls.

plan is to document where sudo is used and review to see where we can either remove the use by not doing the call at all or replacing when something else, like a unix api call.

Have non-root install on single-node and multi-node working WITHOUT having to setup 'sudo'.

At this time, this is what the user will need to do as root user before and during the install process. The main one is having to setup the system logging as root user.

the chmod on some of the directories might work using 666 instead of 777, will be looking into that more.

• • before package install as root user:

chmod 777 /etc/profile.d
chmod 777 /etc/rc.local
chmod 777 /dev/shm
chmod 777 /etc/default
chmod 777 /tmp
chmod 777 /etc/fstab // only for amazon ec2 with ebs external storage

mkdir -p /var/log/mariadb/columnstore
chmod 666 /var/log/mariadb/columnstore
chown mariadb-user:mariadb-user /var/log/mariadb/columnstore

// set user file limits file /etc/security/limits.conf

mariadb-user hard nofile 65536
mariadb-user soft nofile 65536

// systems that support systemctl
// rc-local is used to start columnstore service at boot time

systemctl start rc-local
systemctl enable rc-local

// add to /etc/rc.d/rc.local or /etc/rc.local

/home/mariadb-user/mariadb/columnstore/bin/columnstore start

• • after package install and post-install is executed:

/home/mariadb-user/mariadb/columnstore/bin/syslogSetup.sh --installdir=/home/mariadb-user/mariadb/columnstore install

• • on uninstall as root user before pre-uninstall is run

/home/mariadb-user/mariadb/columnstore/bin/syslogSetup.sh --installdir=/home/mariadb-user/mariadb/columnstore uninstall

A script could be written that a user would run to do the root commands, to make the install easier..

final procedure and code before pull request...

• • before package install as root user:

chmod 777 /tmp // temp area for Columnstore to write temp files
chmod 777 /dev/shm // shared memory
chmod 777 /etc/default // Columnstore libraries directories
chmod 777 /etc/rc.local // file that will auto start COlumnstore at reboot

chmod 666 /etc/fstab // only for amazon ec2 with ebs external storage

// directory for Columnstore logs

mkdir -p /var/log/mariadb/columnstore
chmod 777 /var/log/mariadb/columnstore
chown mariadb-user:mariadb-user /var/log/mariadb/columnstore

// set user file limits file /etc/security/limits.conf

mariadb-user hard nofile 65536
mariadb-user soft nofile 65536

// systems that support systemctl
// rc-local is used to start columnstore service at boot time

systemctl start rc-local
systemctl enable rc-local

// add to /etc/rc.d/rc.local or /etc/rc.local

runuser -l mariadb-user -c "/home/mariadb-user/mariadb/columnstore/bin/columnstore restart"

• • after package install and post-install is executed:

/home/mariadb-user/mariadb/columnstore/bin/syslogSetup.sh --installdir=/home/mariadb-user/mariadb/columnstore --user=mariadb-user install

• • on uninstall as root user after pre-uninstall is run

/home/mariadb-user/mariadb/columnstore/bin/syslogSetup.sh --installdir=/home/mariadb-user/mariadb/columnstore --user=mariadb-user uninstall

--------------------------------------------------------------------------------------------

changes added to post-install and pre-uninstall to reminder users to run syslogSetup.sh

./mariadb/columnstore/bin/post-install --installdir=/home/mariadb-user/mariadb/columnstore

NOTE: For non-root install, you will need to run the following command as root user to
setup the MariaDB ColumnStore System Logging

/home/mariadb-user/mariadb/columnstore/bin/syslogSetup.sh --installdir=/home/mariadb-user/mariadb/columnstore --user=mariadb-user install

https://github.com/mariadb-corporation/mariadb-columnstore-engine/pull/484

Successfully perform a 3 pm gluster install with current 2.1 non-root non-sudo code. So that install works...

Looking into remove some of the need for using the root level directories like
/tmp
/etc/defaults

I dont know how to get rid of /dev/shm since its used by the C++ sharedmemory apis that ProcMon calls. Will need to see if this can be redirected to use a local non-root user directory.

I did replace the need to not use these 2 directories and used local non-root files.

/etc/profile.d to /home/guest/.bash_profile
/var/subsys/lock to /home/guest/.lock

I can help with this if necessary.

Finished the code change to make the use of /tmp dynamic based on install type.

root install will continue to use /tmp
non-root install will use /home/xxxxxx/.tmp/columnstore_tmp_files

I started looking into procmon's /dev/shm usage, and I think the only thing we need root for is the chmod calls on /dev/shm itself. It looks like we're setting the mode to 666, which shouldn't be necessary. I think we can safely get rid of the chmods, replacing them with a test and an error msg at startup.

I'm working on confirming that users do in fact have write access to /dev/shm by default for our target distros.

I don't like this option from previous comment

"I think we can safely get rid of the chmods, replacing them with a test and an error msg at startup."

IMHO we cant have installs failing. Better to find a solution that will always work and not depend on /dev/shm having the correct permissions for a non-root install. The main point with the non-root install is to not use any system level directories like /dev/shm so we wont run into install failures. still best to look for a solution for the non-root install to use a non-root directory like /home/mysql/.shm/dev instead of /dev/shm, if possible..

/dev/shm isn't a system dir, it's just a handle for the shared mem system. But I see that we're also trying not to use /tmp, which is odd. I'll take another look at the doc to figure out what we're trying to do here.

/tmp updates..

This is how the directories will look with latest updates with a new console command:

root install

mcsadmin> getSystemDirectories
getsystemdirectories Thu Sep 27 14:53:00 2018

System Installation and Temporary Logging Directories

System Installation Directory = /usr/local/mariadb/columnstore
System Temporary Logging Directory = /tmp/columnstore_tmp_files

mcsadmin>

non-root

mcsadmin> getsystemd
getsystemdirectories Thu Sep 27 15:44:35 2018

System Installation and Temporary Logging Directories

System Installation Directory = /home/mysql/mariadb/columnstore
System Temporary Logging Directory = /home/mysql/.tmp

finished the changes for /tmp and $HOME/.tmp for non-root user. and completed testing.

2 changes to go, if these are doable

1. non-root use something different than /dev/shm for shared memory
2. possible to setup and use system logging without running anything as root user.

But at this time, im going to run a system regression test to compare the run times from the 'develop' branch and my 'MCOL-520' branch. Want to make sure things are slower with the changes so for.. also testing for functionality in the new branch

will be doing both root and non-root comparions

https://github.com/mariadb-corporation/mariadb-columnstore-engine/pull/587/

Woo Hoo... Got non-root gluster install to work....

It will require sudo setup for 1 command and the changing permission on the gluster log file.

Installing for non-root user gluster will require this extra:

1. install gluster packages on each pm

2. chmod 777 -R /var/log/glusterfs

3. edit /etc/sudoers (with correct gluster path)

mysql ALL=NOPASSWD: /sbin/gluster
mysql ALL=NOPASSWD: /usr/bin/mount
mysql ALL=NOPASSWD: /usr/bin/umount
mysql ALL=NOPASSWD: /usr/bin/chmod

Got Amazon AMI non-root install working.

chmod to this file /etc/rc.d/rc.local

1. chmod 777 /etc/rc.d/rc.local

If using EBS storage:

Add to /etc/sudoers

mysql ALL=NOPASSWD: /usr/sbin/mkfs.ext2
mysql ALL=NOPASSWD: /usr/bin/chmod
mysql ALL=NOPASSWD: /usr/bin/chown
mysql ALL=NOPASSWD: /usr/bin/sed
mysql ALL=NOPASSWD: /usr/bin/mount
mysql ALL=NOPASSWD: /usr/bin/umount

added back in code to run the mysql_upgrade script on upgrade installs..

This is done at the end of postConfigure after the system is up and running. It only runs the script when it detects that a DB already exist

new pull request. I have finished tested all install setups excluding External storage non amazon, so system available to test that. But I beleive the sudo requestments will be the same as EBS excluding

mariadb-user ALL=NOPASSWD: /usr/sbin/mkfs.ext2
mariadb-user ALL=NOPASSWD: /usr/bin/sed

https://github.com/mariadb-corporation/mariadb-columnstore-engine/pull/607/

change to do the mysql_update script during the mariadb/msqyl post-install setup. There was an issue when it was done at the end of postConfigure.

checked into develop for 1.2.1... Patrick and I will continue retesting it from the develop branch.

I have successful done non-root installs for centos 7 and ubuntu 18. On centos 7, I did the standard way and the DBS way (no sudo access during uninstall)

Will test other OS's

Tested debian8/9 ubuntu 16/18

These are the items that this issue was going to try to achieve. Some of them were and others we place into other JIRAs for future releases. Here is more information on each item

Move away from the dedicated split of root and non root installs.
Officially support only os package installs (i.e. rpm deb).
Binary install will still be needed unofficially for dev setups or supporting non standard linux distros.
The os package install should install the columnstore components and run under the mysql user (like server).

This is all covered by new JIRA https://jira.mariadb.org/browse/MCOL-1501

What was done for this jira for 1.2.1

1. Still have separate root and non-root installs
2. Non-root still require the use of binary packages
3. In the documents, we recommend installing and running in the 'mysql' user. but its not required.
4. Only 1 command is required to be done as root and its running the script syslogSetup.sh
5. Some installs will still require sudo commands to be added to /etc/sudoers and its documented here:

https://mariadb.com/kb/en/library/preparing-for-and-installing-columnstore-version-121/#update-sudo-configuration-if-needed-by-root-user