Project

General

Profile

Bug #24045

Avatar?id=14398&size=22x22

freenas offline updater not working when update cache directory forbids it

Added by Joe Maloney over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
Kris Moore
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

I was trying to upgrade 11-RC to 11-RC3

  1. Fetch the update file
    fetch http://builds.ixsystems.com/download/iso/freenas-9.10-releng/amd64/FreeNAS-11.0-INTERNAL-RC3-manual-update-unsigned.tar

After unplugging ethernet...

  1. Trying to run the updates
    tar -xvf FreeNAS-11.0-INTERNAL-RC3-manual-update-unsigned.tar
    manifest_util sequence > SEQUENCE
    freenas-update -C . update

The result "Unable to load http://update-master.ixsystems.com/updates/ix_crl.pem" and the update will not proceed further without an internet connection. I know this is expected for older versions, and there is a workaround. After discussing with Kris Moore he thinks we should fix this before we release 11.

Associated revisions

Revision 981ace9f (diff)
Added by Kris Moore over 3 years ago

Make sure the root-directory of the manual update tarball is set to 755 Ticket: #24045

Revision 99e14cbf (diff)
Added by Kris Moore over 3 years ago

Make sure the root-directory of the manual update tarball is set to 755 Ticket: #24045

History

#2 Updated by Sean Fagan over 3 years ago

  • Status changed from Unscreened to Investigation

blink

Unless something didn't get merged, that should not be the case.

#3 Updated by Sean Fagan over 3 years ago

  • Subject changed from freenas offline updater not working without internet connection to freenas offline updater not working when update cache directory forbids it
  • Status changed from Investigation to 15
  • Assignee changed from Sean Fagan to Joe Maloney

I grabbed FreeNAS-11.0-RC.iso and installed it, from scratch. I then grabbed the .tar file, and then did "ifconfig em0 down".

Ah. Got it.

/var/db/system/update is mode 700, owned by root. The validate update script is run as nobody. So the validation code does the equivalent of:

setuid(nobody)
chdir (/var/db/system/update)
execve("./ValidateUpdate")

however, "." is not readable by nobody. so it fails.

However, you can simply do

freenas-update -v ./FreeNAS-11.0-INTERNAL-RC3-manual-update-unsigned.tar

and it will work. (I tried that.)

Mostly this seems to be okay, but making sure the update cache directory isn't so restrictive would be best. I'm not sure how it got created -- when I ran "freenas-update foo.tar", it got created with the right permissions. (Note that running the script as nobody was a deliberate choice for security.)

Back to Joe for more information and thoughts.

#4 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

Sounds like this doesn't have to be a blocker for 11.0, but perhaps we do want to figure out what is creating that directory owned by "root" on a fresh install. Just to avoid future tickets of "it doesn't work". Joe, thoughts?

#5 Updated by Joe Maloney over 3 years ago

The following works without issues for me as well:

freenas-update -v ./FreeNAS-11.0-INTERNAL-RC3-manual-update-unsigned.tar

I would say not a blocker.

#6 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Status changed from 15 to Unscreened
  • Assignee changed from Joe Maloney to Sean Fagan
  • Priority changed from No priority to Nice to have
  • Target version changed from 11.0 to 11.0-U1

Sean,

Retargeting this for 11.0-u1, just to see if we can fix the bad update dir permissions.

#7 Updated by Sean Fagan over 3 years ago

  • Category changed from 1 to 4
  • Assignee changed from Sean Fagan to Kris Moore

This is a build problem, and will only happen if you manually extract the file:

drwx------  0 root   wheel       0 May 17 15:26 ./

Running "freenas-update foo.tar" doesn't have the problem because it only extracts the files.

To fix this, the build should probably do a "chmod 755" of the directory, just to make sure it's safe, but I will admit I'm not sure if it's the build, or if it's being generated separately.

#8 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Assignee changed from Kris Moore to William Grzybowski

William, just as a final sanity check. I've looked through the build system and can't find anywhere that /var/db/system/update is being set to 700. Nor does this appear on any of my systems here, they all have correct permissions. Do you recall if this may have been a remnant from earlier builds / installs and already fixed?

#9 Updated by William Grzybowski over 3 years ago

  • Assignee changed from William Grzybowski to Kris Moore

Kris Moore wrote:

William, just as a final sanity check. I've looked through the build system and can't find anywhere that /var/db/system/update is being set to 700. Nor does this appear on any of my systems here, they all have correct permissions. Do you recall if this may have been a remnant from earlier builds / installs and already fixed?

As far as I can tell /var/db/system/update is not created by the middleware nor the build system.
/var/db/system is a system dataset (on a pool).

#10 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Category changed from 4 to 1
  • Assignee changed from Kris Moore to Sean Fagan

Thanks for confirming that William. Sean, back over to you. Not sure if there is anything to fix here, the only thing I can find which seems to interact with that directory is the updater itself. Perhaps an older version of it was setting the wrong permissions?

#11 Updated by Sean Fagan over 3 years ago

  • Assignee changed from Sean Fagan to Kris Moore

You misread.

I said the build process. The tarball uses "." for its directory. When manually extracted into /var/db/system/update, it will change the permissions of ".". When extracted using "freenas-update", it does not do so.

The problem is specifically doing:

mkdir /var/db/system/update # if it doesn't exist
cd /var/db/system/update
manifest_util sequence > SEQUENCE
freenas-update -C . update

(I should clarify: the directory that is created and cd'd into doesn't actually matter.)

The easiest way to fix this (for systems that can't do the 'freenas-update foo.tar') is to ensure that the build process -- or whatever creates the tarball, if it's not done as part of the build process -- does a "chmod 755 ." before creating the tarball.

#12 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

  • Status changed from Unscreened to Needs Developer Review
  • Assignee changed from Kris Moore to Sean Fagan
  • Target version changed from 11.0-U1 to 11.0

Sean,

Ok, I think I tracked down where to run the chmod. Can you confirm this looks right?

#13 Updated by Sean Fagan over 3 years ago

  • Status changed from Needs Developer Review to Reviewed
  • Assignee changed from Sean Fagan to Vaibhav Chauhan

Yip, that's it!

#14 Updated by Vaibhav Chauhan over 3 years ago

Do you want to retarget this bug to 11.0-RC3 ? if yes then please create FIX branches.

#15 Updated by Vaibhav Chauhan over 3 years ago

  • Assignee changed from Vaibhav Chauhan to Kris Moore

#16 Avatar?id=14398&size=24x24 Updated by Kris Moore over 3 years ago

Fix branch created / pushed. Thanks guys!

#17 Updated by Vaibhav Chauhan over 3 years ago

  • Status changed from Reviewed to Merged

#18 Updated by Vaibhav Chauhan over 3 years ago

  • Target version changed from 11.0 to 11.0-RC3

#19 Updated by Vaibhav Chauhan over 3 years ago

  • Status changed from Merged to Resolved

Also available in: Atom PDF