my profile | my password | search | faq & rules | forum home

» Film-Tech Forum ARCHIVE   » Operations   » Digital Cinema Forum   » Auto-update (Page 1)

This topic comprises 2 pages: 1  2

Author Topic: Auto-update Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 10-06-2018 10:17 AM                        There is a lot of pressure in the IoT space to have devices support auto-update. This is to combat hacking as manufacturers need a path to resolve vulnerabilities and then push the updated firmware to their customer's devices. This discussion is coming up more and more in regards to the JNIOR which is used in a lot of areas outside of cinema. Presently updates have to be performed manually by customers and, well, that rarely occurs. It is our assumption that the JNIORs in the theater do not have Internet access that would allow it to check for updates. I also understand the "If it is not broke, don't fix it" approach where you really don't want things changing behind your back. I am in this camp myself. Of course, a lot of you still use the Series 3 and there are no updates for those anyway. JANOS for the Series 4 is at v1.7 and updating is highly recommended. What issues would any of you have if we were to add a secure auto-update capability to JNIORs? Would you allow it to do it? I am referring only to an operating system update. Perhaps it would also update the DCP (configuration pages). We would not disturb applications that the unit runs like cinema.jar as those are more specific to your installations. Then there is the question as to when to do the update? It requires a reboot. We could simply queue up the update to be performed whenever you happen to recycle power. Thoughts?  |  IP: Logged Stephan Shelley Jedi Master Film Handler Posts: 854 From: castro valley, CA, usa Registered: Nov 2014 posted 10-06-2018 12:57 PM                     Personally I would hate for this to be like windows 10 where one has little control over the updates. Is the junior that vulnerable to hacking? What is not connected to the outside world can not be hacked.  |  IP: Logged Frank Cox Film God Posts: 2234 From: Melville Saskatchewan Canada Registered: Apr 2011 posted 10-06-2018 02:50 PM                        I can see both sides of this argument, but what's not connected to the Internet can't be auto-updated either, so what we're ultimately talking about is just devices that ARE connected to the Internet.  |  IP: Logged Steve Guttag We forgot the crackers Gromit!!! Posts: 12814 From: Annapolis, MD Registered: Dec 1999 posted 10-06-2018 04:54 PM                     A mandatory auto-update would be a disqualifier for use as an automation system in cinema. It is that cut and dried. As you know, as a developer, sooner or later, you are going to send a bug out. it happens, no matter how well or long you beta test in your lab or select locations. People will always remember the time you took them down. In fact, for me, it would need to be an "Opt-in" situation. With our support program, we provide up to two updates per year. This is not to say that we always update everything twice a year but twice a year we evaluate what the client has, what is available and update them if there is an advantage. When new updates come out, we, personally put them in a holding pattern for, at least a month. Too many times, a patch or update comes out and within 2-weeks gets recalled (just happened on Hollywood Software for patch 10...there is now a patch 11 to fix what patch 10 did). Again, I'm not pointing fingers...it happens. It is impossible to test for every permutation of the way a product may be used. After the grace period, we tend to have our own "beta" sites where they know they have a new release, if not actual beta software. These sites represent the way WE have configured systems so they are a good test for US...if they pass muster there for a couple of weeks, THEN they may end up being pushed (release versions only) to other sites on the regular update program. Critical updates that fix ongoing issues can be pushed off-schedule to relieve a site of problems. The key here is that WE decide what and when gets pushed because ultimately, WE have to answer for a theatre being in distress. So, if you were to put such an auto-update in that was not defeatable, I'd advise anyone against ever installing the product again as I could just about guarantee that you'd, sooner or later would negatively affect some site.  |  IP: Logged Scott Norwood Film God Posts: 8146 From: Boston, MA. USA (1774.21 miles northeast of Dallas) Registered: Jun 99 posted 10-06-2018 07:57 PM                        What Steve said. If the capability exists, its use should be configurable by the user. No one should have patches forced upon him and users who want the patches should have the option to choose when and under what circumstances they are installed. I am all for manufacturers' making it easy for users to patch their products, but the choice of if and when to do so and what version to install should be left to the end user (or the technicians employed by the end user), not the manufacturer.  |  IP: Logged Carsten Kurz Film God Posts: 4340 From: Cologne, NRW, Germany Registered: Aug 2009 posted 10-07-2018 04:46 AM                     Autoupdate should be enabled by default, to cater for larger numbers of IoT devices to be protected from being abused. It should be possible to deactivate this for installers, because, if there is someone actively maintaining them, he is able to install updates intentionally as well. With a device like the JNIOR, where you seem to be able to control the software very tightly, it is probably also a first step to analyse potential security issues and entry points beforehand and e.g. disable them, so that the user/installer need to activate them intentionally. Most abused IoT consumer devices are abused for DDoS because remote access, cloud services, etc are enabled out of the box with weak or public logins, not because of specific code weakness. - Carsten  |  IP: Logged Mark Gulbrandsen Resident Trollmaster Posts: 16657 From: Music City Registered: Jun 99 posted 10-07-2018 08:39 AM                     What Steve said... I shut off all auto-update stuff in software. Especially in Windows 10 systems since they randomly update when ever you are in the middle of doing work. Mark  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 10-07-2018 09:08 AM                        Great feedback. I am on the same page with most of you when it comes to the rest of the world. I went through a phase when I disabled updates everywhere as well. The 24/7 network connection, unsolicited updates and Easter eggs/games aspect of the Tesla knocks it right out of my interests. That's not to mention the expense of the vehicle but I don't appreciate turning something on the next day and being surprised with it functioning differently (good or bad). Or, perhaps, living always in fear that it will not do what I expect it to do the next time I use it. It won't be long before your Tesla forces you to watch an ad. JNIOR is a bit different but let me just put my thoughts on the table and not ask that you accept them. JNIOR is my personal responsibility. I have written 100% of the operating system code it runs (JANOS). Yes, every byte. INTEG is purposely unlike the rest of the world that throws together third party and open source components in an effort to get product out quickly. JNIOR is not a device designed by committee. If there is a bug (and we can recreate it) we can fix it the same day. There are issues that take a little longer and that usually when the symptoms are random. We call those "gremlins". We had a good 'kill' just this past week (the fix now in JANOS v1.7.1-b1 Beta v1). JANOS updates are generally 98% corrective and 2% adding some new capability. We intend always to be 100% legacy compatible. But you are right, we are human and we can make mistakes. Take some comfort that the humans at INTEG can also quickly fix their mistakes. There is no one else I can point a finger to and blame. And, oh yeah, we don't serve any wine before its time. JANOS is at v1.7 and you would be surprised with how many support calls we get where they are running some old version where we know there are tons of shortcomings. We don't get many support calls. Any auto-update capability would be configurable. Presently JNIOR does not 'phone home' for any reason. So its a big step. Security is a big issue obviously for the rest of the IoT space. The JNIOR is not a Linux or Windows system and therefore does not offer the usual set of vulnerabilities. I would imagine that if someone set their mind to it they could certainly hack it or otherwise disrupt its use. It is good to keep it behind a firewall/router. And there is a big difference between JNIOR being able to get to the Internet and the Internet being able to get to the JNIOR. The former would be required for auto-update. We do have units on the open network and keep a close eye on those. There is another approach where the Support Tool automatically gets and optionally performs the updates. But, there are a lot of old Support Tool versions out there too. I am talking only about operating system updates and not application updates which are Support Tool Update Projects. Those will always remain manual as they are now. Those are much more involved. And to Mark's point. The JNIOR is a controller and while a reboot is necessary for an update we would never reboot for the update in any automatic sense. I would plan to have the update queue and be performed when YOU happen to reboot the next time.  |  IP: Logged Scott Norwood Film God Posts: 8146 From: Boston, MA. USA (1774.21 miles northeast of Dallas) Registered: Jun 99 posted 10-07-2018 01:57 PM                        I have not used the JNIOR, but I will suggest one function that many IT devices have: the ability to maintain two or more versions of the firmware and switch between them if an upgrade fails. Most decent network hardware and 'server' motherboards has this feature. The upgraded version gets loaded, but, in the event of failure, a jumper or the sofware equivalent can be set to boot back into the old version. This is useful for testing new software and also for reversion in case of problems. Better yet, would be to add the ability to reset to the manufacturer default configuration (including firmware and settings) in case of signficant problems.  |  IP: Logged Mark Gulbrandsen Resident Trollmaster Posts: 16657 From: Music City Registered: Jun 99 posted 10-07-2018 02:19 PM                     quote: Bruce Cloutier And to Mark's point. The JNIOR is a controller and while a reboot is necessary for an update we would never reboot for the update in any automatic sense. I would plan to have the update queue and be performed when YOU happen to reboot the next time. I'd be for that sort of update, but I wold also want to see facilities to roll the update back to the previous version in case something does not go quite right. The roll back ability is one feature I really like on GDC servers and that I have used several times to save the day. Mark  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 10-07-2018 04:41 PM                        Oh there is a rollback. There has always been rollback. quote: HoneyPot /> help jrupdate JRUPDATE [options] file Options: -U Firmware Update -F Skip confirmation -P Reboot after -R Rollback -C Cancel update Perform installation and updates. HoneyPot /> [CODE] UBB doesn't work? An update involves downloading a UPD file to the JNIOR and executing a JRUPDATE command. This queues the new firmware in a separate Flash memory area. On boot the JNIOR recognizes the pending firmware and performs a swap of the two OS images. This is done in a completely fault tolerant way. So unlike everything else you can feel free to yank power over and over during the boot. The update will complete successfully no matter what you do. The rollback just triggers the swap again. You can jump back and forth. But better than rollback you can poke in any UPD you might have and play musical JANOS versions. The UPD is actually better as it also updates the Java Runtime Library which is not affected by the rollback mechanism. If you've used the Support Tool to load an Update Project the UPD is buried in that update project. You can download them from our websites either INTEGPG.COM or JNIOR.COM. There is a article or two in the Knowledge Base on JNIOR.COM covering OS updates. I envision the auto-update queuing the OS update like JRUPDATE but there may be some particulars that we would have to develop in making it perfect. I also have an idea that an application like CINEMA could schedule the reboot if there is a pending update. It could be a macro you define or something. I'd just want to do it in a completely acceptable way perhaps meeting your approval. But we are also looking at JNIORs running 1000+ street lights in some cities. Those need to update somehow. We don't feel the need to force anyone to update their JNIORs. It is just scary when we find sites running ancient versions. Especially considering the list of issues that have been addressed since. For support calls our initial recommendation is always to load the latest OS version to see if whatever problem you have has already been corrected.  |  IP: Logged Scott Norwood Film God Posts: 8146 From: Boston, MA. USA (1774.21 miles northeast of Dallas) Registered: Jun 99 posted 10-07-2018 05:56 PM                        That all sounds good!  |  IP: Logged Harold Hallikainen Jedi Master Film Handler Posts: 906 From: Denver, CO, USA Registered: Aug 2009 posted 10-07-2018 11:24 PM                        Interesting discussion! The approach I've taken is updates are pushed to the devices (generally through a web page). The update is copied to external flash, then copied back to internal flash in the microcontroller. Should it fail, the user can hold down a button or two on power up to copy the factory image from external flash back to internal flash. For large deployments, we have a script that pushes updates to devices (using curl). After doing the update, it checks for success. If any update fails, the script exits. The idea is you have, at most, one dead unit instead of hundreds. I remember many years ago a wire service for radio stations (the news was printed on model 15 Teletypes) send out an update over the wire killing all the demodulators in the country. They had to send a tech to every site to swap an EPROM. This is what I try to avoid! Harold  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 10-08-2018 07:18 AM                        JNIORs have always been able to be updated in the field and the approach has pretty much remained the same since day one. I think I first implemented it in 2005. While anything can happen we have not 'bricked' a unit yet. Most of you have experienced updates using the Support Tool and an Update Project. An OS update can be part of that and the basic update procedure is handled for you. Updating the OS directly is fairly simple. I'll describe it for the Series 4. Once you see how that is done then maybe we can talk around how it might happen in a somewhat more automatic sense. First you need a UPD file. This has a UPD file extension and it contains an image of the new OS plus the Java Runtime Class Library (etc/JanosClasses.jar for the unit). You copy this file typically to the /temp folder on the JNIOR either through FTP or by dragging and dropping it in the DCP. Next from the Command Line you run the JRUPDATE -U command which loads the OS into Flash in the swap area I mentioned previously. The UPD file contains checksums to insure that it has not gotten damaged in transit. JRUPDATE won't load it and trigger the update if there are any errors. When you reboot or cause JRUPDATE to reboot the update is performed as I described a few posts back. The JRUPDATE command does replace the Java Runtime immediately. If you loaded the UPD file in the /temp area it is automatically removed with the reboot. We try to publish the MD5 or SHA256 digest code with the file so you can check that the file is authentic. After you load the UPD in the /temp folder you can run the MANIFEST command to get its MD5 or SHA256 and compare them. I can show details if anyone wants. But that procedure is a little too much of a pain that likely no one bothers. Also while we have the MD5 or SHA256 digest displayed on JNIOR.COM it is likely not present on INTEGPG.COM as its value is questioned since Rick pushes use of update projects. So there are a few things that need to happen BEFORE any kind of automatic update process could be implemented. 1) While the Series 4 can make connections secured by TLSv1.2 we should also add a digital signature to the UPD. Basically that adds the SHA256 to the file in a way that cannot be altered and so it can be automatically checked instead of manually. You want updates to come from us and be official. Could you imagine if the hackers hacked the Microsoft update servers? Same for Linux flavors I guess? 2) We need a secure 'phone-home' mechanism so JANOS can find out what are the current versions of things. This could initially just post to the jniorsys.log system log a message indicating that there is a new update available. No one would probably notice and it is passive. You might note that JANOS complains once and a while in the system log when it sees that you are still using the default passwords. 3) We need to add a feature to JRUPDATE that allows it to reach out to our servers and fetch the UPD for you. This would basically provide an easier means of getting the UPD file into the /temp folder under your control. It would allow an update to the latest JANOS version all with a single command. I can do all of this and none of you should have a complaint or concern. Of course none of it would work until you first updated to whatever JANOS version supported it. But with the above in place an automatic update would be straight forward to later implement.  |  IP: Logged Marcel Birgelen Film God Posts: 3357 From: Maastricht, Limburg, Netherlands Registered: Feb 2012 posted 10-08-2018 06:43 PM                     I think that we're all on the same page that for any professional production environment, automatic updates should be off the table. No matter if the underlying system is a complex and often overly bloated OS like Windows or a Linux distribution or a more to-the-point embedded approach. Every update comes with a risk, even fixing a bug can break stuff, because my solution happened to work around the bug and the combination of my workaround and your fix might break stuff... That being said, automatic updates being an option sounds totally fine to me, as long as I can opt-out of it and please, for anything not being targeted as a home solution, don't make it the default. Furthermore, I hate convoluted update procedures. Many of those embedded gizmos make you jump through a 1000 hoops in order to get them updated, just to put up a few examples: - Running a local TFTP server, because why support something "modern" like FTP or even HTTP? - Updating involves a 10-page upgrade path, in where you end up updating bootloader 1.43 to 1.45 before you can apply OS image 4.32-Mental-Green, from which you then can upgrade to 5.2-Shady-Pink - Loading a web page loading a Java applet which was signed by a root certificate expired 5 years ago - Finding the correct update requires registering to your convoluted and website (after being redirected 5 times, because the company that built your appliance was acquired by that other company which was then acquired by yet another big company that then changed its name after some other big-shot merger), often even requiring expensive subscription services, while burying the actual firmware update somewhere, 10 layers deep within a 5 mile list of useless "software listings". HP(E), Dell(EMC?), Cisco... I'm looking at you. What I actually would like is, something like a "embedded gizmo update console"... You know, some server or service where all the embedded "little" critters like switches, routers, access points, fridges, toasters, automation controllers... you name it... would register themselves and would allow ME to manage the updates. Imagine all those little devices talking some common update protocol, where you can manage and enroll updates centrally, all from that same console, without the need of manually logging into each device or the need to install bloated "management consoles" from all the different vendors that come up with their own, mostly convoluted solutions. Imagine the same solution would even allow me to backup device configurations... Something like that would obviously require some cooperation on a common API... but yeah... I'm still allowed to dream, am I?  |  IP: Logged

All times are Central (GMT -6:00)

This topic comprises 2 pages: 1  2

Printer-friendly view of this topic

Hop To: Select a Forum: Category: Operations -------------------- Digital Cinema Forum Film Handlers' Forum Large Format Forum Ground Level Feature Info, Trailer Attachments & REAL Credit Offsets Category: Community -------------------- Film-Yak Film Handlers' Movie Reviews The Afterlife Bob Maar's Joke-A-Thon Category: Classified -------------------- Equipment and Supplies Wanted/For Sale Help Wanted/Seeking Employment Category: System -------------------- Software Beta Testing Forum

The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion and agrees to release the authors from any and all liability.