Upgrade 9.2.1.7 to 9.3 Success Stories?

[TAC]

I understand that postings here a somewhat slanted to those having issues, but how about some success stories?

I'm running 9.2.1.7 and would really like to pull the trigger and upgrade to 9.3. Although I'm pretty much a noob I can following instructions. Problem is, if I get off in the weeds, I'm pretty much screwed.

I have watched a number of videos and read a bunch of stuff, but a number of success stories, and even some comments on what to look out for would be very encouraging.

Unless I'm overwhelmed with positive feedback I'm afraid I'll stick with 9.2.17 (which is working great!).

Thanks,

-TAC

 

[cyberjock]

The question is so ambiguous that it's pointless to even ask.

Some people have had problems because of incompatible hardware, some because the don't even meet the minimum specs, others for various weird bizarre configurations. So unless we plan to go into a multi-page lengthy discussion of what is or isn't going to cause problems you'll find out if/when you try to upgrade.

 

[TAC]

With most people posting to the forum complaining about one thing or another I just thought it might be refreshing and/or informative if 50 guys posted here that they upgraded without a hitch.

Although somewhat vague, don't you think that might be somewhat helpful?

Is my hardware compatible, will I have any problems upgrading? Supermicro X10SLL-F LGA1150 MoBo, Xeon Quad E3-1220 V2 3.1GHz CPU, 8GB ECC memory.

 

[cyberjock]

I upgraded from 9.2.1.7 to 9.3-alphas without a hitch. Aside from problems while in beta and such it's been good to me. No problems at all aside from the already documented and fixed ones. /shrug

I'm waiting for a little more info on this jail bug with old jails being in /mnt/mnt/pool instead of /mnt/pool before upgrading my main rig to 9.3. I do have another box that is my ESXi datastore that I'll probably upgrade to 9.3 this weekend. I just want to find a reliable USB stick as the one I have is a really crappy one and not one I intended to use long-term despite using it for 5 months. :D

 

[cyberjock]

Well, I just upgraded my ESXi datastore server from 9.2.1.9 to 9.3 via the WebGUI and had no problems. My boot device is USB and it took about 30 minutes and several reboots. But I sat patiently and let it run and it finished with zero problems.

 

[TAC]

cyberjock, Thanks a lot! That's exactly the kind of info I was looking for. Tips me a little closer to pulling the trigger even though from reading the forum you appear a FreeNAS expert. ;-)

If upgrading from 9.2.1.7 to 9.3, is using a (reliable) USB stick the way to go as compared to the System|Advanced|Firmware Update button from the GUI?

 

[Ericloewe]

cyberjock, Thanks a lot! That's exactly the kind of info I was looking for. :) Tips me a little closer to pulling the trigger even though from reading the forum you appear a FreeNAS expert. ;-)

If upgrading from 9.2.1.7 to 9.3, is using a (reliable) USB stick the way to go as compared to the System|Advanced|Firmware Update button from the GUI?

If you're going to overwrite the current boot device, might as well do the GUI update. It's easier.

If you're installing to new media, boot the ISO from whatever you please and choose the new media.

 

[Neomancer]

Worked for me eventually. Initially I used my existing USB key, but that failed to install.

I then did a new install on a new 8GB key. Install proceeded OK, after install it hung for a long time (5 minutes+) on Booting 'Normal Boot'.

I started to think something was wrong, but eventually it kicked off and booted up fine. I reimported my volumes and the old config. Then things went wrong again, getting the CSRF error stated here. Haven't applied the fix yet, but everything on the box, Plex etc is running.

 

[Mlovelace]

Mounted the ISO over IPMI and installed on mirrored USB thumb drives (going to see how they last, might move to SSDs). Uploaded my 9.2.1.9 config and rebooted. No problems.

 

[bob p]

I just did the upgrade and encountered a couple of bumps in the road. I updated using the GUI. Here are the problems I ran into:
1. after uploading the upgrade and checksum, the system hung while unpacking the upgrade. after an hour, i had to close the window and repeat the procedure.
2. on the second time, the upgrade window closed, and opened a brand-new upgrade window, prompting me to start the whole process over again (back up the config file, upload the update, input the checksum).

I closed the redundant update window. The logs appeared to show that the update was successful, with lots of activities and no evidence of any failure. the final exit code was zero, so I rebooted. 9.3 came up without any problems.

overall, the update process was fairly painless, if you know what you're doing well enough to ignore the erroneous behavior of the GUI and check the log files. In that respect, I'd have to conclude that the GUI portion of the install is still buggy and needs some errors to be fixed.

 

[danb35]

Mounted the ISO over IPMI and installed on mirrored USB thumb drives (going to see how they last, might move to SSDs). Uploaded my 9.2.1.9 config and rebooted. No problems.

Ditto. My 9.2.1.9 installation was on a 4 GB stick, so I needed something bigger anyway. And in case it went sideways, I can still plug the old stick back in. So far though (a couple of days in), no problems at all--the Plex plugin works, my other jails work, my shares work, etc. I haven't yet installed the system update that's available (I'm in the middle of burning-in some new disks first), so can't comment on that yet. Also haven't upgraded my pool; I'll give it a week or so to give any snags time to show themselves.

 

[bob p]

I'm seeing the following error being repeated in my logs:

Dec 24 23:44:21 ***servername*** notifier.py: [freenasOS.Configuration:491] Unable to load http://update.freenas.org/FreeNAS/trains.txt:

Evidently, this is occurring because my FreeNAS server is in a secured environment and is not allowed to access the Internet.
If you're not seeing this, then I'd wager that you've granted your server Internet access. We don't do that here.

 

[danb35]

Evidently, this is occurring because my FreeNAS server is in a secured environment and is not allowed to access the Internet.
If you're not seeing this, then I'd wager that you've granted your server Internet access. We don't do that here.

Well, since 9.3 is designed to check periodically for updates and prompt you to install them, this would seem like expected behavior.

 

[bob p]

> this would seem like expected behavior

I've got a few comemnts about that:

1. Any server "appliance" that assumes it has internet access and attempts to contact the outside world without the explicit permission of the sysadmin suffers from a design flaw that makes it inherently insecure. In a secure environment the sysadmin must have the ability to limit access to a server from the external world, and to the external world from the server, in order to ensure that data remains secure. Maybe home users will think that auto-check for updates is a good idea, but nobody who is security conscious would consent to operate a server under this paradigm.

2. Any "phone-home" feature needs to have a toggle selector on it so that it can be turned on/off at the will of the sysadmin. Any system lacking such a feature is poorly designed.

3. People with valuable data lock it down. If modern "accepted practice" principles of firewall design are followed, then in a production environment any server that is not functiong as a bastion host is going to be locked-down by two firewalls operating in series -- an exernal/screening "access" firewall on the perimeter network, and an internal "choke" firewall on the internal network.

4. It's important to understand the bug that I reported, and why it's really a bug and not the feature that it has been suggested to be. Consider Paradigm A, in which the appliance is intended to go out to the internet, search for updates, and apply them. Consider Paradigm B, where the appliance is denied self-authorized internet access -- the appliance is intended not to contact the internet, updates are obtained manually in a secure fashion, and the securely-obtained updates are installed by a sysadmin as a separate operation.

It's one thing for the appliance to function properly under Paradigm A (as was suggested above), but it's something entirely different for a program to explicitly fail when operating under Paradigm B. (that's the problem I was reporting).

Getting back to my firt point and refining it a little: An appliance that can be configured to function under either Paradigm A or B is well-conceived. If it can only function under Paradigm A then it is poorly-conceived. If it is designed to function under Paradigm A or Paradigm B at the sysadmin's direction, but fails under Paradigm B, then it suffers from a bug.

5. The developers have decided that the appliance fails to function as intended when operating under Paradigm B, because the execution of updates is dependent upon internet access. The bug report (already resolved) states that the behavior that I have observed is ineed a bug. The good news is that this bug has been fixed in the past few days. If there are any doubts, check the bug reports and the nightly builds.

 

[cyberjock]

Ok, so I want to say a few things:

I agree 100% on your comments about best security practices, etc etc etc. That being said, please read below. ;)

There is nothing to stop you from downloading the updates and applying them via the "old" manual method. It will still work, and the manual method was left in specifically for situations where the server might not have internet access, by design or on accident.

As for the calling home thing, that's something I could easily argue either way. On one hand if it's already calling home to check for updates, why not get something like a hardware ID just to provide information on how many installs are out there. I don't know how much information is passed, but I can assure you that nothing that would be "sensitive" such as passwords would be sent. I'd imagine the server likely reports on what services are used just so we know what people use. If nobody uses a particular feature then why spend lots of dev resources on it. Likewise if everyone uses CIFS, then focus should definitely be spent there. There's been some discussions about where to put developer resources in the past because there's no solid numbers on who uses what.

@jkh would be the person to ask about what is or isn't transmitted, and would be the person you'd want to talk to to convince him to add some kind of command line feature or switch in the WebGUI to turn off calling home. I'm not a fan of software that "calls home", but I can see the advantages of having it call home. If I knew where the code shows what is sent when it calls home I'd like you to that just so you'd feel better about what is (and isn't) included in those transmission. He might respond here since I just tagged him, but you can probably find him in IRC if you pop into #freenas in the evenings Pacific Time.

Edit: Also I want to add that you *can* manually download the templates and actually setup the jail and plugins entirely offline, if desired. Granted it's easier if the server is online, but them are the breaks. Off the top of my head I can't think of anything in FreeNAS that won't work if the server has no internet access. Some things may or may not be ideal (like NTP time syncing, Plex on the internet, etc.) but the core functions in FreeNAS should work just fine.

 

[jkh]

> this would seem like expected behavior

I've got a few comemnts about that:

See the GUI. There is nothing about checking for updates that is not user-configurable. You should also be careful not to conflate incoming with outgoing firewall policies, as you did in your reply. There is nothing about the FreeNAS update procedure which requires *inbound* access, as you strongly implied, and as someone more than a little familiar with security best practices in a very wide variety of deployment scenarios, I find such assertions both jarring and unduly alarmist. The update system reaches *out* for an update, if allowed to do so. It reaches *out* for the CRL, so that revocation can be supported, and then it validates the signature(s) of any packages it downloads against internal signatures. In no scenario is your box expected to be externally reachable. Thanks.