Can Developers Work in a 'Locked-Down' Environment? 648
brad-d queries: "My company is seriously considering enforcing a SOE on all employee computers, including developers. The level of lock-down would likely include baring the Windows registry from changes (and in effect stopping the installation of new software). The goals of this SOE are to prevent users from installing unlicensed software, plus some support issues. What are others experiences with situations like this? Can a developer really work in a lock-down environment? What compromises could be made between developers and IT services? And no, Linux would be likely banned." It depends on how "locked-down" said environment is, and what the developer would be will be working on, however if the Registry is locked with no mechanism provided for the Developer to add in whatever keys are necessary, how much real developing can one do?
Yes, but at a much slower rate... (Score:4, Interesting)
They're migrating to W2K shortly, but I put my foot down and they allowed me to wipe my box and install RedHat on it -- the only way I managed that was the fact that it was in a nice shrinkwrap box.
Well, all fine, but I get no support and I'm not allowed to put it on the network, so it's sneakernet for me. Access to the internet is done with floppies. =(
The point is that you may be able to persuade them to let you have a purely standalone machine, as long as you keep an SOE machine next to it for running Outlook =)
Development Lab (Score:3, Interesting)
Where I used to work at we had something similar called the time warp lab, that had a bunch of machines running different versions of windows with different components installed. The developers could test their code on them, and when we were done, we just ghosted a new drive image onto the drive.
Re:Registry lockdown? (Score:2, Interesting)
This is what happened for us. (Score:2, Interesting)
After we received a request for an email tool we bitched and bitched about getting the rights to load it on a networked PC as well as SOME info on how our Mail servers worked. They said no so we delivered the product as is. Surprise of Surprises it didn't work right.
We the programmers then got all the rights back that we had before. All it should take is some truly crappy releases from your developers before they give you back at least some of your user rights.
Just make sure that you document all of your hassles before you release it:)
Not viable (Score:1, Interesting)
http://www.sysinternals.com/ntw2k/source/regmon
And download a registry activity monitor...browse/ do you regular work and then look at the log.
Locking down the registry is a very stupid idea.
Let me answer from the opposing view... (Score:3, Interesting)
Unfortunately many companies don't house full-time developers and instead prefer to outsource on a per-project basis. Because of this many of them are concerned only with making their app run, at the expense of others. ie - Develop an app that's dependent on IE 5.0 despite the fact many company sites only work under IE 4.0. Bad code all around, eh?
This leads many companies to implement lock-down and I have to sympathize. In a perfect world all your tools would be installed by your Desktop folk and even your development PC would be locked down. In a more realistic world you would have a more open development platform but all testing would be performed on a locked-down PC. A nice compromise since it affords you the freedom to install the tools you need (I think historically no Desktop support technician has ever installed Visual Basic 100% the way a developer wants it!) while still ensuring you are developing an app that doesn't stomp all over settings and files that other apps rely on.
Also, keep in mind that there is (essentially) no user context in Windows that "locks down" the entire registry. What it does is grant full access to user areas and no access to system areas. The only big difference here between "secure" *nix and "insecure" Windows is that in Windows full control is the default. There's no reason why lock-down has to be a bad thing for a developer. In fact it's often a good thing as it prevents the next developer in line from writing an app that will kill yours.
Hey, no problem... (Score:3, Interesting)
In fact, when I first got here my system was locked down like a prisoner by accident (they thought I was an intern...god I hate being young) and I didn't notice for four months, and then only because I installed JDK 1.3.1 (which wanted to change my JavaPath).
Yes, Java CAN interface with the registry, but it's a heck of a lot easier to use object dumps and ini files (in xml of course). And since things don't need to be "registered" (more trouble than it's worth) due to the namespace and classpath, you end up with a very nice sandbox development environment.
I wish this effing COM object I've been trying to teach how to use the network all morning were written in java...
Re:Registry lockdown? (Score:2, Interesting)
When I was attending Purdue in the mid '90s, all the computer lab machines would reload a disk image over the network after every reboot. It only took about 10 - 15 minutes to get a login after starting a reload, and you were guaranteed a completely fresh environment. It sucked if you only needed to print out a file from a floppy for that class that started three minutes ago. On the other hand, you never had to worry about malicious code. No viruses, trojans, password sniffers, etc. It made maintaining the machines that much easier. Each lab had its own master image and any updates could be tested on an admin workstation before the updates were published. Once the image was published, every machine was updated at the next reload.
Re:Registry lockdown? (Score:1, Interesting)
NT, on the other hand, has much finer grained security, and there are thousands of developers, let alone users, without a clue how to properly implement the security features of NT.
But go ahead and blame it all on 'Winblows' and show us that you're not ignorant.
Nope. You're certainly not!
the described scenario is the exact one i work in (Score:3, Interesting)
1. tiny apps. just like the recent post. [slashdot.org] since single executeables do not need to muck with the registry to run, you are able to utilize small powerful ftp clients, html editors, etc.
2. build your own box. i put my case to my manager's manager, and they made an exception for me. i had (until the sept 11 wtc disaster, in which my workstations were turned into crispy critters) 4 computers at my desk. two were standard company-wide locked-down builds, and the other 2 computers they let me install nt server from scratch. nt security just made sure they had admin rights on them in case the box did something not quite right. then of course, software support washed their hands of these boxes. i had to install my os and software, i had to maintain it. if i screwed something up on the box, it was all for me clean up. which was fine for me, i'm a developer, i can support my own box. i want to support my own box!
3. write stateless software. change your paradigm. become one with the great zen of concise programming for the wrong reason: not because you should, but because you have to.
other tip: depend on nothing. my profile with it's personal settings blows up from time to time and is reset to the generic sucky settings and i have to personalize all of my standard apps all over again. after awhile, i made sure not to put too much faith in leaving my desktop and depending upon it to look the same the next day. batch job important standard settings to rejigger everything (drive mappings, odbc connections, etc.) in cases of nt alzheimer's.
finally, there's no getting around it, a locked down SOE sucks for developers. developer= power user. developer= someone who HAS to muck around with things regular users don't. so bring this up with management. you guys are special, obviously, the most thick-headed manager can see that. maybe, before they SOE everyone, you can convince them to firewall all you dangerous developers in your own domain and let you hack your installs to your hearts content, unsupported, insecure, untrusted, but necessary to build apps.
Re:Ding! Ding! Ding! We have a winner! (Score:1, Interesting)
There are some extremely valid reasons to insist that developers have to take some pains to have admin rights to their NT machines.
1. Developers can easily "assume" admin rights when developing their software - and then blithely write software that requires write permission to an admin only area for example.
This could have easily resulted in a very expensive problem had I not caught this during building of the application for that development team at a very large (top 5 in world) finacial instituation I once worked at. Since the developers had admin rights they wrote a Java application that stored all config details in the Windows directory - very bad, but very subtle.
2. Developers having admin rights to machines means that they can build and install their development tools anyway they want, and they can patch/not patch as they see fit.
When the time comes to build the applications they are developing this can result in subtle errors and problems - both in interim development builds between members of the same team (who have differently built NT workstations) and when the code moves from development to production - during which it would likely be built on "standard" build servers - the wrong set of patches to a compiler or different shared libraries and the resulting code will differ considerably.
Note further that such issues are not usually solved by standard source code administration practices (CVS, MS SourceSafe, ClearCase, MKS Source Itegrity etc) all of which usually do not track the installations, builds, and patches of the OS, compilors, and shared libraries.
3. Have you ever witnessed the example of developers using beta or pre-release versions of libraries, compilors, or OSes? And then wondering why problems crept up when they moved their applications to production. Witness the recent problems at MS where code had been built against beta libraries - which left debuging turned on for applications that were then moved into production
Corporate development is a tradeoff between developers and the requirement of running the business - if you are developing on the fringes - or in a research lab environment that it is one thing, but when you are developing applications for the business's production environment (or to be shipped to clients or made available for sale) then rigorous and documented processes should be followed with regards to the machines that are used to develop and build the applications, if you don't you will eventually get burned.
I speak from the experience of working with over 1000 developers building and supporting over 650 internally written applications.
Locking down Windows (Score:1, Interesting)
I believe that SOE is the right way to go. For developers give them two PC's one for doing their job (programming, e-mail, etc) and another for testing. If the developer is a high level develop (builds Apps with Visual Studio or Delphi), you will need to give them local admin rights to their work PC because a lot of the development tools can only be installed and used with admin rights. Perhaps lower level developers (Access, Web development) you might be able to lock down their PC's.
Make the developers responsible for maintaining their PCs. Provide them a build Disk or CD to re-install the OS and standard office apps if they screw up something and can't fix it. Desktop support should only provide support for hardware issues for developers (Bad HD, Nic, etc).
I have personally setup dozens of business with custom installs of Windows NT in a locked down environment. I've created custom unattended Win NT installs that install the OS, Service packs and Patchs, Standard Apps (MS-OFFice, Outlook, IE/Netscape, AcroReader, ICA Client, Terminal Emulation, CAD/CAM, Client-Server Apps, etc). The Standard build is installed from a DOS floppy that determines the hardware model, nic and installs a clean install of NT and standard apps. Its so easy, even a stupid user could rebuild their own PC.
Application installs, upgrades, and Patches occur during lights out. As long as the PC is connected to the network, upgrades can be performed during non-business hours, so that users aren't impacted during the day. The lights out installs also manages available network bandwith so that only a limited of workstations are upgrade at a time (upgrading a 1000 PCs at the same time is a bad thing!)
I've created custom NT services to allow non-privilege users to perform some privileged functions, such as installing a network printer, or installing a business supported application.
Re:They can't (Score:2, Interesting)
A few years ago, we had what we thought was a rigorously controlled machine that had the minimum revision levels of the O/S that our applications were supposed to work with. This machine was used for testing and for building the final distribution of the application.
A few days before building a production version of the app, IT used their domain adminstration ability to add a simple 'run once' item to the machine to do a simple service pack installation. Unfortunately, this was not noticed in time, and when we logged in to do the shipping build - Did you know that some Microsoft build environments automatically make the application require that the target machine have at least the same or later version of all DLLs and COM components as the build machine?
So we shipped the app suite to the beta customer sites, the installation runs fine, but the apps all complain about missing DLLs and components.
Of course, the IT domain adminstrators no longer have administration privileges on the development area boxes - and now we have our own development domain. Central administration (from outside the department) and a properly controled development environment both require absolute control over machine configurations - but the development department needs multiple configurations. The two versions of control are incompatible. And that's just for test and build machines.
Even if you are developing in Java, you might not get the same results from two different JVM versions (if it's Microsoft JVMs you will, anyway).
Final answer? Let IT control machines that are used for IT functions, and let developers control machines used for development functions.
IT v. Dev is worse than Mothra v. Cowboy Neal (Score:2, Interesting)