I need to create a documented, clean and reproducible development environment. I'm climbing the Vagrant learning curve (as used with VirtualBox), and it's the perfect tool for this. To be able to type
$ vagrant init ubuntu/trusty64
$ vagrant up
and have a VM ready to go is amazing and powerful. I've been crafting a Vagrantfile with all my needed tools, and life seems to be good.
Except... there's a big problem. Vagrant is designed to treat the details of what boxes and versions are available, where they come from, what are the differences, etc. as "magic" to be hidden from the user. This is wonderful for the beginning programmer, but in a professional development environment this can be deadly: if a box is unexpectedly updated, or if my coworker gets a different box, the build may break in extremely subtle ways. As an experienced developer, I know that this way lies madness.
I know about the Hashicorp Vagrant atlas, but that still just lists versions on enormous web pages, with no information on what the differences are. I also know about the hack of taking an Atlas URL and adding a .json suffix, e.g....
web page describing box: https://atlas.hashicorp.com/ubuntu/boxes/trusty64
JSON describing box: https://atlas.hashicorp.com/ubuntu/boxes/trusty64.json
... but this is a kludge at best, as it's a pain in the rear to track this down, the JSON format isn't made for people to interpret, and there's still no information on just what changes from version to version.
I even fired up Wireshark to watch Vagrant's traffic when downloading ubuntu/trusty64. Much of the traffic was encrypted, but I did find that although the Vagrant CLI printed the box URL as https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20160919.0.1/providers/virtualbox.box, the box was actually being downloaded from http://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box. And, the header of the box file included a lot of interesting information about just what the box would be emulating (disk partitions, processors, etc. etc. etc.).
Needless to say, I shouldn't have to do this. The Vagrant CLI should provide information about a named, not-yet-downloaded box:
a description of the box
a list of available versions
what a specific version added compared to the previous version
where a specific version is hosted
what the configuration of the box will be
who created it
etc., etc., etc.,
So, is there an official way to get this sort of information for a named, not-yet-downloaded box?
Related
My CFIDE just went crazy this morning and I can't locate the what is causing this. When I log in from example.com/cfide/administrator/index.cfm some of the tabs on the left work fine and some are showing the index page of example.com like in an iframe... I restarted the app server but the issue is still there. Any recommendations on how to debug this thing?
So for posterity here is what we found.
There are two possibilities of exploits that could be affecting you:
the bitcoin exploit (miner.d)
the ckeditor file upload exploit (this is the h.cfm file)
There are others but these are common and known. Both tap underlying java to unfold work that either calls something more sinister, delivers server meta data or unrolls a scheduled task to fireoff worker bees to consume resources doing something the admin is unaware of.
So as we discovered we have a varietal of this h.cfm called fusebox.cfm (obfuscated with bonus encrypted CF5 garble). If you can open the file you will see that h.cfm file and open it you will see UGLY and Obfuscated code but not very sophisticated. A lot can be revealed by a coder's code and if you deconstruct and format this particular code you will discern that the developer is not native to CF, and jumps from script style to CMFL style (in caps no-less).
(here is the Stack Overflow link with the raw code (be careful))
It is also named: i.cfm, h9.cfm, r.cfm, adss.cfm or fusebox.cfm here is the black hat page that give you a ton of info. I'm viewing the cached site because I don't trust the blackhat sites. (because one loaded something on my system that raised an antivirus alert).
The file may be unreadable so here is a link to a site that describes some github sourcecode that can decrypt it for you. That is Coldfusion 5 crap that still floats around now and again. (I'm pretty sure it will look similar to that code in the SO link I pasted above).
Post mortum: One more coldfusion serve saved from villainy. Remember, it never hurts to run through your systems and see if anything can be found like this. It also never hurts to make things a little more difficult for would be server exploiters ;)
I've been checking out Faxien+Sinan and Rebar, and the basic philosophy of Erlang OTP seems to be, install applications and releases on a single Erlang image instance. What are the best practices for keeping releases self contained? Is there a way to package releases such that you don't have to modify the site for machines that you're deploying to? How about gathering all dependencies into the codebase for management?
Perhaps I'm going against the grain... I come from a Java background and the philosophy of "nothing pre-installed but the JVM" seems very different.
IMHO this can't be answered in a few sentences. You should have to read some parts of the included documentation, especially "Erlang/OTP System Documentation" (otp-system-documentation-X.Y.Z.pdf, with X.Y.Z being the version number), or have a look at the book "Erlang and OTP in Action" because throughout this book there is "one" example of a "service" with different "parts" from the first steps, using Erlang/OTP concepts and finally building a "release".
IMHO this is currently the best book around, because it not only introduces Erlang, but also shows what OTP is and how OTP is used for a project. And it is not just a collection of loose samples, but everything is build around a single project.
I'll describe the approach that currently works for me for regular (often daily) releases to a small number of instances on EC2:
I set up my project with rebar and check it into github.
All of my dependencies are listed in my rebar.config file (they too are on github).
My Makefile looks similar to what I described here.
My EC2 image only has a regular build of erlang and no other libs installed by default.
To create a new node, I spin up an instance, clone my git repository, and run make. This will fetch my dependencies and build everything.
To update my code I do a git pull and a rebar update-deps. Depending on what changed I may restart the node or, quite often, I'll attach to the running node and reload the updated modules. It helps to have start and attach scripts as part of your project.
It may be helpful to look at how a project like webmachine is packaged.
I don't know much about the standard OTP release management system, other than it looks like a lot of work. Because this seems counter to rapid deployment, I never gave it a serious try - though I'm certain it makes sense for other projects.
I want to develop simple HTTP filter (transparent proxy).
I want it to support all versions of Windows including XP and above.
From the folks that have experience with this, what problems should iIexpect when installing the service?
There are some that I could quickly think of on top of my head:
-You should be aware that you have to cover all browsers or at least major ones like IE, firefox, chrome, safari and opera. The ways they use Winsock are different, eg overlapped vs. non-overlapped IO.
-Installation/Uninstallation is challenging as it's very easy to mess up and end up losing internet connection.
-It is even more challenging if there is other LSPs already installed. Your LSP might interfere other LSPs and vice versa.
-It's very common that Windows PCs pre-installed with anti-virus. Some of them provides proxy-like internet filter as well, eg. Avast and Kaspersky. As being winsock applications, anti-viruses are also loaded with and controlled by your LSP. Once your LSP breaks these antivirus and their net filters, expect no network connection for any other apps on your computer.
I could list more but that could cast away your hunger to dive into this challenge. Start doing it first and you will get know it better along the way. Good luck!
OK, so I began a little journey to move all of my development into virtual machines, and Virtual Box seemed like the best choice to pursue. So I get it installed and install Ubuntu and get my development environment set up, and after some tweaking it works as advertised. Yay, I think to myself, this is GOOD STUFF! But, thankfully, before I got too engrossed in pushing forward with development, I decided to simulate some computer disasters and see if the Virtual Box could handle it and still be reliable. Long story short, I am not impressed. After a few days I started to realize that life with Virtual Box would require constant network setting tweaking, command line maintenance, and manually overriding IP addresses/DNS addresses/Network Adapter settings etc. I did some searching about the network settings stuff, and found tons of posts with people having networking related issues (and no real solutions). Also, the snapshots (which are stored separately from the disk image) are a pain in the ass to use, and a lot of effort and care and command lining needs to be taken to recover the right version of the VM. In the end I decided that it was more trouble than it was worth. Which is sad, because in theory Virtual Box could be a great product. And the very first time you install it and use it, it is great! But if I cannot reliably and consistently recover the VM in the correct state with minimal effort on any computer at any time, its no good to me.
So, can anyone else verify my findings? Or vouch that Virtual Box really does work as intended, and point out what I'm too stupid to realize?
Which version of VirtualBox are you running? If snapshots are a PITA, then maybe you're running a version before 3.1. They added snapshot branching fairly recently (like four months ago, maybe?) which precludes the need for figuring out how to manually copy the image files around. And frankly, if you're doing that, then yes it's a real PITA, and VMWare is way easier.
My biggest beef with VirtualBox is that you can't take a VM and move it, plus its snapshots and branches to another PC. The only method I know of is to export a virtual appliance, and then import it. Although I was relieved to recover my TeamCity installation after a hard disk crash, I was still bummed that I had lost all history of my snapshots up to the point where I exported the virtual appliance.
But overall, I still really like VirtualBox. I haven't had any issues with network settings as you have mentioned.
Can anyone list the steps needed to programatically install an application on Windows. Aside from copying the files where they need to be, what are the additional steps needed so that your app will be a first-class citizen in Windows (i.e. show up in the programs list, uninstall list...etc.)
I tried to google this, but had no luck.
BTW: This is for an unmanaged c++ application (developed in Qt), so I'd rather not involve the .net framework if I don't have to.
I highly recommend NSIS. Open Source, very active development, and it's hard to match/beat its extensibility.
To add your program to the Add/Remove Programs (or Programs and Features) list, add the following reg keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PROGRAM_NAME]
"DisplayName"="PROGRAM_NAME"
"Publisher"="COMPANY_NAME"
"UninstallString"="PATH_TO_UNINSTALL_PROGRAM"
"DisplayIcon"="PATH_TO_ICON_FILE"
"DisplayVersion"="VERSION"
"InstallLocation"="PATH_TO_INSTALLATION_LOCATION"
I think the theme to the answers you'll see here is that you should use an installation program and that you should not write the installer yourself. Use one of the many installer-makers, such as Inno Setup, InstallSheild, or anything else someone recommends.
If you try to write the installer yourself, you'll probably do it wrong. This isn't a slight against you personally. It's just that there are a lot of little details that an installer should consider, and a lot of things that can go wrong, and if you want to write the installer yourself, you're just going to have to get all those things right. That means lots of research and lots of testing on your part. Save yourself the trouble.
Besides copying files, installation tasks vary quite a bit depending on what your program needs. Maybe you need to put an icon on the Start menu; an installer tool should have a way to make that happen very easily, automatically filling in the install location that the customer chose earlier in the installation, and maybe even choosing the right local language for the shortcut's label.
You might need to create registry entries, such as for file associations or licensing. Your installer tool should already have an easy way to specify what keys and values to create or modify.
You might need to register a COM server. That's a common enough action that your installer tool probably has a way of specifying that as part of the post-file-copy operation.
If there are some actions that your chosen installer tool doesn't already provide for, the tool will probably offer a way to add custom actions, perhaps through a scripting language, or perhaps through linking external code from a DLL you would write that gets included with your installer. Custom actions might include downloading an update from a specific Web site, sending e-mail, or taking an inventory of what other products from your company are already installed.
A couple of final things that an installer tool should provide are ways to apply upgrades to an existing installation, and a way to uninstall the program, undoing all those installation tasks (deleting files, restoring backups, unregistering COM servers, etc.).
I've used Inno Setup to package my software for C++. It's very simple compared to heavy duty solutions such at InstallShield. Everything can be contained in a single setup.exe without creating all these crazy batch scripts and so on.
Check it out here: http://www.jrsoftware.org/isinfo.php
It sounds like you need to check out the Windows Installer system. If you need the nitty-gritty, see the official documentation. For news, read the installer team's blog. Finally, since you're a programmer, you probably want to build the installer as a programmer would. WiX 3.0 is my tool of choice - open source code, from Microsoft to boot. Start with this tutorial on WiX. It's good.
The GUI for innosetup (highly recommended) is Istool
You can also use the MSI installer built into Visual Studio, it's a steeper learning curve (ie is a pain) but is useful if you are installing software in a corporate environment.
To have your program show up in the Start program menu,
You would need to create folder
C:\Documents and Settings\All Users\Start Menu\Programs
and added a short cut to the program you want to launch.
(If you want your application be listed
directly in the Start menu, or in the programs submenu,
you would put your short cut in the respective directory)
To programically create a short cut you can use IShellLink
(See MSDN article).
Since you want to uninstall, that gets a lot more involved because you don't want to simply go deleting DLLs or other common files without checking dependencies.
I would recommend using a setup/installation generator, especially nowadays with Vista being so persnickety, it is getting rather complicated to roll your own installation
if you need anything more than a single executable and a start menu shortcut.
I have been using Paquet Builder setup generator for several years now.
(The registered version includes uninstall).
You've already got the main steps. One you left out is to install on the Start Menu and provide an option to create a desktop and/or quick launch icon.
I would encourage you to look into using a setup program, as suggested by Jeremy.