I've found a simple way to get by this.
http://www.davidmoore.info/2009/12/02/running-32-bit-remote-desktop-connection-on-windows-64-bit/
Solution: Rename the 64-bit mstsc.exe from System32 to prevent it from replacing the 32-bit process.
This is simple if you have rights to rename that file. If you’re on NTFS you may get a “You require permission from TrustedInstaller to make changes to this file” error.
To get by this error, you can take Ownership of the file and give yourself full permissions:
- Browse to %SystemRoot%\System32
- Right click mstsc.exe and choose Properties
- Go to the Security tab
- Click Advanced
- Go to the Owner tab
- Click Edit
- From the “Change owner to:” list, choose your user name
- Click OK
- Go to the Permissions tab
- Click Change Permissions…
- Click Add
- Enter your user name and click OK
- Tick the box in the Allow column for Full control
- Click OK
- Click OK
- A Windows Security warning will come up; click Yes to proceed
- Click OK
Now, you can rename the file mstsc.exe to something like mstsc.exe.bak
Then, you can launch mstsc.exe from %SystemRoot%\SysWOW64 and you will have 32-bit Remote Desktop Connection running.
Right, a more formal answer:
Don't start guessing on a ubuntu/debian system where to put things. Ubuntu has pretty up to date versions, and aptitude is a very good package manager. You really want your server to have the following traits:
- To be secure
- To be well organized, so that you know where things should be
- To have a repeatable configuration, by some method. ( This is why I am big on the packages. Even without puppet, you can get a list of packages that are installed, and in an emergency just install that list and you are back to where you were, if you were hacked for example )
For Nginx, here is a how I get an updated package quite soon after they come out:
https://launchpad.net/~stevecrozz/+archive/ppa
You mentioned that you were new. Use the package managers. In your case, aptitude. We used to build from source all the time, but since you did not mention 'firewall' or 'security' then time is short.
Software that you install locally to a system goes in /usr/local. /usr is owned by the package managers really.
As for /opt, I use it for really weird stuff, like macports on my laptop or things I'm trying out, like coldfusion server ...
Default nginx goes into /usr/local/nginx , which is very good since if you build from source , make uninstall ... most likely wont be there.
http://library.linode.com is a really good basic resource. Read that too.
Once the reality of app dev with simultaneous server admin sinks in, you might want to check out
http://puppetlabs.com and get hooked up with puppet. That's for later
The nginx I told you about has the following options:
nginx -V
nginx version: nginx/0.8.48
TLS SNI support enabled
configure arguments: --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-0.8.48/modules/nginx-upstream-fair
Now, later in life you might want to recompile for some other modules. ( /usr/local ) !
But regardless, you'll see the debian/ubuntu way of laying this stuff out. at least. A beloved trick i use is to install some server I need to build and copy the base config files, then purge it.
Good luck. BTW create a user for yourself, research sudo, and disable root logins. First thing I do on a fresh server.
Best Answer
Honestly, this depends a lot on what you're doing with the server, and what your expectations are.
If you're building a box that can handle short periods of (scheduled) downtime without problem (updates/upgrades) and isn't running a mission critical service, running Ubuntu's latest stable is going to be fine. Just remember that it will require updates if it's going to remain in production for a length of time, and plan appropriately.
If you're building a box that needs maximum uptime, or if you plan to run commercial software that might offer limited compatibility between versions, then an LTS release is going to be your best bet. This will allow you to run longer (with security updates available) before you have to upgrade or retire the box. Also, as mentioned, many commercial software companies won't support all releases, but will support LTS to simplify things on their side.
Now, as this is for a server, I would tend to lean more towards the LTS release. Server hardware rarely changes extensively once it's in production, and it's easier to verify that hardware before putting it into use. Additionally, on the server side 64 bit support is quite good (in my experience) and very stable. I doubt you'll have a need to upgrade frequently just for better 64 bit support.