We need to install a Subversion server on one of our production web servers. I know this is not best practice but we have a distributed team of developers so we need it accessible to them and our web-facing server options are limited. Anyway, what is the correct method for installing VisualSVN on an active Win 2003 server? When I started the install it wanted to use ports 443 and 80 so I stopped the installer. Our existing sites are already configured for the HTTP ports. How can I install VisualSVN and not clobber our current sites?
Answer: I installed it using port 8080 and skipped SSL since we dont require it anyway. It works great alongside the other sites.
Related
I can run Spark on necessary port on localhost, but I can't find info how to run my site on my own domain name (not localhost).
Should I also run and configure any webserver, such as Apache Httpd?
OS: Windows Server 2008 R2, JRE 8.
You'll have to follow the instructions from your host provider. For example, I have an app hosted at OpenShift. Openshift recomends the use of CNAME records, I just followed their instructions, and my app is on air.
I was hosting 3 websites from my home server with IIS and due to all of the issues I ran into like sendmail with a php script, I completely uninstalled IIS from Server Manager and installed xampp. I am using Windows Server 2012 R2. Apache will not start due to port 80 being used. I have already tried many of the fixes scattered across the web. Things I have tried:
-Web deployment agent Service has been disabled
-World Wide Web Publishing service is not on any list of services for my PC-Skype is not installed on my PC-MSSQL Server Reporting Services is disabled - I have ran netstat -aon | findstr :80 an serched for all prosesses with port 80, and PID 4 which is NT Kernel & System.
This is where I am stuck, I can not for the life of me find out what is using port 80. I know I can change apache's listening port to 8080 or whatever but I do not want to do that as the URL would have to show that. Is it possible I could have a virus? Are there other ways to narrow down what could be causing this?
Probably the easiest thing to do is point a browser at your server and see what pops up. Sometimes a shutdown and then a restart (not a restart from the Start button, but an actual shutdown) helps clear up various M$ server issues. Good luck!
I have a windows 8.1 machine running ubuntu 14.x on a virtualbox. I'm running meteor inside that virtualbox. I've bridged the connection and turned off the firewall on both machines. I'm able to connect to the internet from the virtual box, and I can telnet from the windows host into the ubuntu machine.
I can also connect to meteor apps that are not using the force-ssl package; however, I CANNOT connect to meteor apps that are using force-ssl!
If I run "meteor remove force-ssl" I can connect to the app. Any thoughts? Thanks.
EDIT - by connect to the app, I mean "http://[ip_address_of_guest]:3000/" in a browser on the host machine. I've tried both http and https.
I'm new to Meteor but, from this documentation, it looks to me like you are seeing the intended behaviour ...
"This package, part of Webapp, causes Meteor to redirect insecure
connections (HTTP) to a secure URL (HTTPS). Use this package to ensure
that communication to the server is always encrypted to protect users
from active spoofing attacks.
To simplify development, unencrypted connections from localhost are
always accepted over HTTP.
Application bundles (meteor bundle) do not include an HTTPS server or
certificate. A proxy server that terminates SSL in front of a Meteor
bundle must set the standard x-forwarded-proto header for the
force-ssl package to work.
Applications deployed to meteor.com subdomains with meteor deploy are
automatically served via HTTPS using Meteor's certificate."
This answer clarifies.
I am about to try the Digital Ocean guide, "How To Deploy a Meteor.js Application on Ubuntu 14.04 with Nginx", myself to see if it correctly documents the required set up steps. I'll update with my results.
I'm using a Debian VPS on DreamHost and wanted to install a feature-rich customer issue-tracking system (not for software development like Bugzilla). OTRS made my shortlist and I followed the Installation Instructions through the "Web Server Configuration" step (/etc/init.d/apache2 restart), but the restart step reported failure. Nevertheless pgrep apache showed it was running. In fact, it turned out that although www.mysite/otrs/installer.pl was running, my regular website showed a page claiming it had no content (but when I looked in the website's folder, its content was fine, just not being served).
DreamHost Support was very helpful, but explained that they don't use the standard Debian Apache server for hosting websites and instead use their own. Specifically, the Debian server is in /etc/apache2, but the DreamHost server is in /dh/apache2. DreamHost Support determined that the OTRS installation instructions were configuring the usual Debian Apache location which somehow prioritized that server instead of the DreamHost server. They tried moving the otrs.conf file into /dh/apache2, but though the regular website was working again, the OTRS page wasn't.
Has anybody had success installing OTRS on a DreamHost VPS?
I've consulted one of our admins on this, and these are our suggestions:
You will either need to:
Adapt DreamHost's Apache build to incorporate the OTRS modifications
Get Debian Apache up and running
Both options will require an admin user and some knowledge of Linux command line and Apache management tools. You will also need to set your VPS to UNMANAGED, which means that any changes in the DH Web Panel to any of your domains will have no effect whatsoever. Just make sure the DNS records for any domains are pointing to your server. You will also need to be able to manage your own Apache configurations.
NOTE: This will also essentially mean that DreamHost support cannot and will not troubleshoot your domains. Unmanaged means unsupported in any way!
There are a few core differences between DreamHost's apache2 configuration and the default Debian build. The first issue I observe is that DreamHost's configuration does not allow for extra configuration files to be loaded in the manner that the OTRS documentation suggests. This means if choosing option 1, you will need to manually insert the OTRS directives into DreamHost's configuration files, which may prove difficult.
I would recommend moving or otherwise disabling the /dh folder entirely after setting your VPS to unmanaged. This will not allow DH-default Apache to start when the VPS starts. You may also need to remove the DH Apache startup script in /etc/rc3.d/S02httpd2 and the actual script at /etc/init.d/httpd2.
Once you have your own version of Apache running successfully, you might consider copying the VirtualHosts that were previously at /dh/apache2/apache2-ps/etc/httpd.conf into your own domain configuration files in your conf.d directory, or you can shuffle your website files around and configure your Apache to your desire.
Once you've got your own flavor of Apache running, you should be able to implement the OTRS instructions per their wiki. :)
I used nmap to check which ports are open on my server it showed
PORT STATE SERVICE
9090/tcp open zeus-admin
now port 9090 is supposed to listen for apache tomcat. What is this zeus-admin ?
how I start my apache tomcat server ?
It is also the default listed name when nmap'ing it. The actual service listening to that port doesn't have to be, it's what is usually the default service running at that port.
Zeus Web Server is a proprietary web server for Unix and Unix-like platforms.
ZWS seems to be dead since it hasn't been updated since January 2010, and the company no longer offers a similar server solution.
It's probably fine to just kill it, and remove it from operation as it's mostly just a security risk by now.
Zeus is sometimes used as an embedded web server for things like admin consoles. If you have the OpenFire XMPP server installed, you will find the configuration UI tools running on port 9090 (http://localhost:9090).