I'm looking at hosting a number of small, static websites and have been looking at a few alternatives including G-WAN. At the moment I'm just trying to get a feel for how well each server suits my needs before picking one.
G-WAN seems to do exactly what I want, though I'm running into problems with updating the configuration (by adding new folders) after the server's started. I can't find anything in the documentation or online about this, so I don't know if I'm doing anything dumb, running an unsupported configuration, or whether it's a feature that doesn't exist in G-WAN.
Here's my setup:
G-WAN 3.3.28 64-bit on Ubuntu 12.04.1 LTS.
I have what I think is the required minimal folder structure:
0.0.0.0_80
#0.0.0.0
www
$site.com
www
$othersite.com
www
I startup gwan via (I'm still messing around, so hopefully ):
sudo .\gwan -d
Everything works brilliantly. I add $thirdsite.com/, $thirdsite.com/www/, and $thirdsite.com/www/index.html; then when I try to visit thirdsite.com it gives me the root host (ie it doesn't seem to pick up the changes).
To reload the modified configuration, I have to either do:
sudo .\gwan -k; sudo .\gwan -d
or kill the non-angel process (kill -s 15) to restart the child process.
Can G-WAN reload the host definitions another way? If so, is it something that works out of the box or is there a command that can cycle the server without dropping requests made to other hosts (/is it safe to kill -s 15 on the non-angel process + if so, is there a reliable way to identify the process)? Thanks in advance!
G-WAN loads the host definitions at startup and does not check them as time goes to reload them dynamically.
To force a reload, you have to stop the child process (when in daemon mode) and v3.9+ keeps the old child alive the time to process any pending request while the new child accepts new connections.
Since stopping the child can also be done from the maintenance script or from a handler or from a servlet by just running exit(0) there is not need for a dedicated command.
Note that when you use kill you can pick the pid file from the gwan directory:
the parent process starts with a capital letter: Gwan_xxxx.pid
the child process starts with a lowercase letter: gwan_xxxx.pid
That will make your life easier.
Related
I'm pretty new to networking and am trying to do some simple configuration for a server for LAN access ( SSH & HTTP ) using iptables. I'm using CentOS7 if that matters.
I've been working form tutorials and they seem to suggest as the first step to flush all the existing rules.
I'm working on a new CentOS install and I have a couple terminal windows of rules and I definitely don't know enough to try to restore them if I kill them and I definitely don't know what they do so I'm afraid if I kill them networking issues I don't understand will start happening or I'll open my server to security risks.
In these tutorials they don't bother to explain why flushing the current rules is done.
Am I OK without flushing as long as there's not another rule in place that conflicts with the ones I add at the end?
If I do flush will everything be restored at restart as long as I don't use iptable's save?
Flushing the current rules is not required but sometimes it's better to start with a clean slate. Even if one doesn't want to break the current configuration, it might prove more beneficial to rebuild it entirely from scratch. That is, not just in respect to the simplicity & efficiency of the resulting configuration, but also mentally while trying to come up with the correct rules.
If one chooses to keep the current configuration and build upon it, he should bear in mind that the order of the rules matters. The -I argument can be used to insert new rules into a specific position in a specified chain, as written in iptables man page:
-I, --insert chain [rulenum] rule-specification
Insert one or more rules in the selected chain as the given rule number. So, if the rule number is 1, the rule or rules are inserted at the head of the chain. This is also the default if no rule number is specified.
Before modifying anything, it is advisable to save the current configuration to a file:
iptables-save > <filename>
This file can be used later on to restore the original configuration:
iptables-resotre < <filename>
Rules created with the iptables command are stored in memory. If the system is restarted before explicitly stating otherwise, the current rule set is lost. On CentOS7, this is done by:
service iptables save
The details of this command line can be found here:
This executes the iptables init script, which runs the
/sbin/iptables-save program and writes the current iptables
configuration to /etc/sysconfig/iptables. The existing
/etc/sysconfig/iptables file is saved as
/etc/sysconfig/iptables.save.
The next time the system boots, the iptables init script reapplies
the rules saved in /etc/sysconfig/iptables by using the
/sbin/iptables-restore command.
Note that on CentOS7, firewalld was introduced to manage iptables. This answer explains how the classic iptables setup can be restored.
in Solaris 10, when server restart, the backup daemon (tina_daemon) does not work properly when calling for another executable to shutdown the application services.
however, when manually restart the backup daemon, the calling for the executable works fine.
I found the following lines in the log-file:
8|9|tina_daemon|780|1|3|1373964994|1373964994|10739|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Event handler daemon started|0|~|~|~|~|~|~|
8|9|tina_daemon|880|256|3|1373964994|1373964994|10739|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Service opened, host "<host name deleted>", Time Navigator Enterprise Edition Version 4.2.8.8 P4680|0|~|~|~|~|~|~|
8|14|TNUnixSocketImpl::initNetServiceTcp|11|1|1|1373965001|1373965001|10963|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Unable to bind 5 socket, retos=125 "Address already in use"|0|~|~|~|~|~|~|
8|14|vos_init_net_service_tcp|1|1|4|1373965001|1373965001|10963|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Unable to initialize network service of TCP type, retex=TN_ERR_CONFLICT_RESS (conflict in access to the same resource)|0|~|~|~|~|~|~|
is it a potential that not enough share memory? since the tina_daemon use 2 ports which already define in the /etc/services
I feel very weird since when manually using root to restart the tina_daemon, everything works fine. When server restart with the startup script (which i changed to similar to manul restart), it does not work well for calling another executable to shutdown the application. It shutdown the application half way, and cause the application hang (and ultimate need to restart the application)
I am working on a simple Perl app that copies another Perl app and builds all the required Apache config files.
The thing I can't seem to figure out is how to reload the apache config on the fly. I know I could do a system call and reload apache there, but that would mean I would have to get root access to this app, and that is a little scary.
Is there a way to ask apache to reload its config files from within the CGI container?
-------------------------Additional info------------------------------
I have done some more research and the problem is that Apache must be run with elevated privileges to bind to port 80. So one solution would be to set Apache to run on another port and forward that port to 80 via iptables. (This may be a last resort but a very messy solution).
Here is what gets me, Apache should be able to maintain its current port bindings and recheck its config files, all I am doing is adding another script alias.
Is there any way to add a new script alias with out a reload?
you also have the options to reload the config:
/etc/init.d/httpd reload
or
apachectl -k graceful
But unfortunately, those need root also. This differs from a normal restart in that currently open connections are not aborted. A side effect is that old log files will not be closed immediately. This means that if used in a log rotation script, a substantial delay may be necessary to ensure that the old log files are closed before processing them.
Also, if running Apache with daemontools you can do this by:
svc -h /service/apache
Sorry to ask a question then not give some one else the opportunity to answer but I figured out a solution and I hope it may help some one else.
What I had to do was leave the config alone it is not possible to reload in the manner that I required with out root privileges or some fancy port forwarding (That would make this application less portable than I would like).
So the only thing that Apache appears to load dynamically is the file system.
What I have done is used mod_rewrite to redirect the script requests and simply put them in /var/www/appname/copyname/cgi-bin/
So I have a few machines in production that are running a Sinatra app on top of Rack. Usually everything is hunky dory until Puppet - which we're using to sync changes to our servers - notices that the Gemfile.lock for the project has changed, and as a result, needs to issue the bundle install --binstubs --deployment command so we get the new gems. When this happens, ANY http request will cause a 500 error when it calls into Bundler to require our gems, because the new gems haven't been installed yet.
We usually have at least one Rack process hanging around due to another process that periodically makes an http request to ensure the server is alive, but when this happens, there are no Rack processes alive. It seems like the PassengerMinInstances directive might help if the problem were with new instances, but we also have a process that periodically fetches a page to test that the server is still up, so there still should be at least one Rack process alive to handle the request.
I should probably note that puppet doesn't actually restart Rack (by touching the restart.txt file) until after the bundle install has completed, so it doesn't make any sense why our Rack processes would go away at this time. Has anyone encountered anything like this? Is there some Rack option to not reload the entire environment on every request that I've overlooked?
I know this doesn't directly answer your question, but what I've done in the past to get around this kind of thing happening is to deploy the app into version-numbered dirs with a soft link pointing to them and an (Nginx) proxy server routing requests to the link. At the end of the deployment the deploy script points the link to the new app.
It seemed to work well enough for me, and if things really go wrong you can always manually repoint the link back to the previous version.
For posterity's sake, I'll answer this question. As part of the deployment, all of the files were touched with chown -R, which updates the ctime (but not the mtime) of the file. There is also an interesting bug/feature in Passenger where they will restart the server whenever the mtime or ctime of the /tmp/restart.txt file changes.
Solution: stop chowning the directory during a deployment.
Lets say I have an Emacs-Server running on some remote server, with all the libraries and software necessary for running my application.
Then I want several clients to connect to that remote machine, using Emacs-client. Does each client need a full Emacs installation, or is there a minimal installation that is just enough to communicate with the remote server, where all the action is?
Could this (Emacs-)client installation be so minimal, that almost all software-updates can be done on the server, without affecting the Emacs-clients?
Is there a reason not to run the clients remotely as well, and simply use a local display? That way, pretty much all you need on the local machines is the ssh client and the X Window server.
ssh -X (user)#(server) "emacsclient -c"
Edits for the comments:
This command starts a new client to connect to an existing Emacs server (which it assumes is already running). You can use "emacsclient -a '' -c" to automatically start emacs --daemon if there is no existing server, but I don't know whether you want the connecting user to be starting the server.
In fact, I'm pretty unsure about the whole multi-user side of this to be honest, as I've never done that before. Authentication for the above is handled by ssh, but there may well be subsequent permission issues to deal with, or similar, when the server and the clients are started by different users.
This approach should be possible with Windows/Cygwin as client and/or server, as Cygwin provides Emacs, OpenSSH, and X.org packages. (I regularly use Windows/Cygwin as a local display for Emacs running on Linux.) It may be harder to set up, though, and any permissions issues are probably different when you're using Cygwin.
I'm less sure how this would work without Cygwin. NTEmacs certainly won't talk to X.org, so I imagine you'd be terminal based in that instance. (There are probably other options, but Cygwin sounds to me like the best-integrated approach to using all of Emacs, SSH, and X on Windows).
Lastly, I imagine you're probably getting your "Connection refused" error because localhost is not running a sshd daemon? I would say that configuration of ssh is outside the scope of this question, but there are lots of resources online for that.
Depending on what you're trying to achieve, you may be able to use a combination of Emacs and Screen. By starting up Emacs from Screen on the remote machine and detaching from it, you can subsequently re-attach from a different machine that doesn't have Emacs. Again, whether this will work for you or not depends on what you're trying to do; however, for many Emacs use-cases, this can be very effective. If you're not familiar with using Screen in this manner, here is some reading material:
screen - The Terminal Multiplexer
I am not sure that would be possible. emacsclient uses tramp to connect to a remote server, and just by looking at the number of requires in the tramp elisp files (41) it seems very unlikely. You can try it yourself with the following:
zgrep -oE "\(require '[a-z-]+\)" *el.gz | sed -e 's%[a-z0-9-]\+\.el\.gz:%%g' | sort | uniq -cu | wc -l
I'm not an expert in emacsclient, but I don't think is was designed to do what you're looking for. I think the general use case is that emacsclient allows you to redirect new requests to open a file with emacs to a persistent emacs process to avoid what may be a bit of an overhead in startup time. You seem to be looking for more of a true client/server relationship.
I think to meet the goal you're aiming at you'll probably need to look a little outside emacs, probably a project unto itself - 'emacsRemoteClient. It boils down to one or two models; the file you want to edit would need to have it's path sent over to the server machine so that emacs could do some sort of remote tramp access & then spawn the xwindow locally (using the local X env or requiring an x server on windows)... or two, transferring the file to some temp location on the server box and again spawning the remote x window locally (followed by syncing the changes between the tmp & local file).
Would be cool to have something like that... but suspecting it'll involve a bit of work. Maybe we just need a version of emacs written in javascript and it can live in the cloud or on your browser... oh to have emacs keybindings in the browser ;-)
-Steve