Bug #1257

one start is too picky about one_auth

Added by Carlos Martín about 9 years ago. Updated over 8 years ago.

Status:ClosedStart date:04/26/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:Release 3.8
Resolution:worksforme Pull request:
Affected Versions:OpenNebula 3.4

Description

If one_auth is not present, this section of share/scripts/one makes 'one start' to abort in installations with a mysql DB

    if [ ! -f "$ONE_DB" ]; then
        if [ ! -f "$HOME/.one/one_auth" ]; then
            if [ -z "$ONE_AUTH" ]; then
                echo "You should have ONE_AUTH set the first time you start" 
                echo "OpenNebula as it is used to set the credentials for" 
                echo "the administrator user." 
                exit 1
            fi
        fi
    fi

History

#1 Updated by Carlos Martín about 9 years ago

Now that I think of it, maybe the one script is not picky enough. If one.db exists, the one_auth file is not checked, but the scheduler needs it to contact oned.

#2 Updated by Shantanu Pavgi about 9 years ago

Carlos Martín wrote:

Now that I think of it, maybe the one script is not picky enough. If one.db exists, the one_auth file is not checked, but the scheduler needs it to contact oned.

I didn't know scheduler process would use ONE_AUTH file to communicate with the oned. I got confused by the error message - "You should have ONE_AUTH set the first time you start OpenNebula as it is used to set the credentials for the administrator user." So I thought it won't be needed afterwards which seemed reasonable as server process wouldn't need authentication file which is used by clients.

Following was my test scenario which made me think oned won't require ONE_AUTH file to start. I guess the assumption is still valid as oned doesn't need ONE_AUTH file but it's the scheduler process that needs it.

# Unset ONE_AUTH
$ unset ONE_AUTH

# OpenNebula assumed default ONE_AUTH path
$ one -b start
Could not open file: /home/pavgi/.one/one_auth

scheduler failed to start

Then I set ONE_AUTH to inexistent file:

$ export ONE_AUTH=/tmp/one.auth
$ one -b start
Could not open file: /tmp/one.auth
scheduler failed to start
/home/pavgi/project/cloud/one/bin/one: line 76: 25072 Terminated              $ONED -f 2>&1

Next I added invalid authentication parameters to the ONE_AUTH file:

$ echo "shantanu:pavgi" > /tmp/one.auth
$ one -b start
# starts OpenNebula related processes 

So OpenNebula processes started fine with an invalid ONE_AUTH file. However OpenNebula client commands from the same session on the server host should fail as authentication parameters are incorrect.

$ onehost list
[HostPoolInfo] User couldn't be authenticated, aborting call.
# Point ONE_AUTH to a file containing valid credentials 
$ export ONE_AUTH=~/.one_auth
$ onehost list
  ID NAME               RVM   TCPU   FCPU   ACPU   TMEM   FMEM   AMEM   STAT
   0 kvm-04             6   2400   2386   1950  47.1G  39.3G  35.1G     on

So I guess there are two issues here: * As you have mentioned in the earlier comment the ONE_AUTH should be checked regardless of one.db existence * And may be the scheduler process should check for a valid ONE_AUTH file while starting the process??

#3 Updated by Ruben S. Montero over 8 years ago

  • Status changed from New to Closed
  • Resolution set to worksforme

Thanks Shantanu Pavgi for yout deatiled comments. The only way to check for a proper AUTH file is starting oned and try to communicate with it. This information is in the sched.conf file.

Although it'd be nice to check that at start-up time, this is very basic configuration step (and the logs in sched.conf), so IMHO just checking ONE_AUTH is enough. Marking this one as works-for-me.

Also available in: Atom PDF