I've collected in a manual test a lot of URIs below a target. As the host is a local environment, I'd like to run the same scan against the same set of URIs in the QA environment. Hence, the hostname of https://:4443/app/... should change in https://:443/app/...
Related
I have taken over a project that has an AWS ec2 elasticbeanstalk instance running a socket.io server.
I have logged in via and done the following steps.
SSH in
cd /var directory.
ls > account app cache db elasticbeanstalk empty games kerberos lib local lock log mail nis opt preserve run spool tmp www yp
I can't see to find the socket server code? Nor the logs for the socket server?
I am not sure where they would be located.
There are myriad methods to get code on to a server and to run it. Without any information about the code or the OS or anything else, assuming its a Linux based OS, if I’m looking for something and know what it is, I can usually find it by searching for a string that I know I will find inside at least one of the files on the server.
In this case, since its a socket.io, I’d search for socket.io:
grep -rnw '/' -e 'socket.io'
The result will show me all files, including the full path, that contain “socket.io”, and you should be able to determine where the code is pretty quickly.
After I deployed my app into cloud foundry got the following error message:
ERR Timed out after 1m0s: health check never passed.
Of course on my local machine works perfectly.
You should change your health check type.
if the application does not expose a Web interface you need to change the healthcheck type to process.
Valid values are port, process, and http.
To configure a health check while creating or updating an application, use the cf push command:
$ cf push YOUR-APP -u process
See the Health Check doc for more information:
https://docs.cloudfoundry.org/devguide/deploy-apps/healthchecks.html
Based on the discussion in the comments and my own testing of the actual application you are deploying, it appears that this particular app takes an age to start. Possibly related to individual Java service timeouts (as you have not bound any CF services to the application).
Anyway, while I'm not sure what the actual problem is (possibly an issue with PWS itself), this can be sort-of worked around by specifying the -t option when doing a push, or adding the timeout: <int> attribute to the manifest (see the manifest documentation.
OLD ANSWER
Need more details to be sure, but I imagine one of two things are happening:
You are not using the correct port. Cloud Foundry exposes the port it expects the application to be deployed using the PORT (or, pre-Diego, VCAP_APP_PORT) environment variable. This defaults to 8080, so if your application is not listening on 8080 (or is bound to 127.0.0.1 instead of 0.0.0.0), then the health check will fail.
Your application does not expose any API endpoints, and should be deployed with the --no-route option on CF, and (starting with Diego) needs to have cf set-health-check [app-name] executed against it. This should only be done if your application genuinely does not need a health check.
Some build packs can take care of the first automatically for you. Which build pack are you using? Or, alternatively, which language are you using?
You can disable the health with the below command
(Short term solution)
cf push app_name -p target/app.jar -u none
I am running a Dotnet 3.5 executable in Windows 7 Ent, as a GPO computer startup script in a domain. The script resides on a network share. The exe is run as Local System. The exe runs correctly.
I would like to access a web Service in this exe, but it appears that the Local System does not have access to network resources per documentation. However if the same exe is copied to the C Drive and run from there under the same account and same conditions (i.e. GPO startup script) then the Web Service can be accessed.
How is it that the Local System has access to the web service when running from C: drive, but not from the Network Share? Is there anything that can be done to make it work from the network share, without first being copied to the local drive? is Local System same as SYSTEM and same as NTAuthority\system?
I have tried the following so far to make it work. None of these work:
Impersonate a domain user in code.
Give Full Trust to all zones in .Net Security Configuration
Add the network share to Trusted Sites in IE.
Use the netbios name instead of the fully qualified name of the fileserver, i.e. \server\share, rather than \server.domain.com\share
The following things I cannot do to fix this problem:
Change the logon account of the Group Policy Client service to a domain user
Run the exe as logon script. It has to be startup script.
To reproduce this problem I do the following:
Create an simple exe with some network function, i.e. WebClient.DownloadString("http://www.google.com")
Deploy exe to a network share
Run as normal user to show there is no error
Run whoami to show the current user
run psexec -s -i cmd.exe
Cmd will start as SYSTEM (Local System or NT Authority\System)
Run whoami to show the current user
Run exe from network share to show it will fail to download the page.
Copy the exe to C Drive.
Run exe to show the page is downloaded.
I am migrating my vCenter Server 5.5 to a new server (databases have already been moved to a new SQL server and all is OK on existing vCenter Server 5.5 implementation). When I begin the simple install process on the new vCenter Server host the Single Sign-On component presents me with an IP address of 10.10.10.117 as the ip address of the FQDN file01.xxxxxxxxx.com. This is the iSCSI interface address. I need it to use the 10.1.1.17 ip address that is the address of the production NIC that the ESXi 5.5 hosts will be communicating with. I have already changed the binding order of the NIC cards and flushed the DNS cache. I also added file01.xxxxxxxx.com with the proper IP address to the hosts file and also file01 to the hosts file. Still, during the install, 10.10.10.117 is discovered. Thanks in advance! Babak C.
Just to get a quick clarification...are you freshly installing vCenter 5.5? Or are you migrating an existing vCenter server to a new host and using the update utility to upgrade? I am assuming you are doing a fresh install based on your details about the SQL server and SSO. Here is my suggestion, in case it is a fresh install.
We had a similar problem with 5.5 on a new install where the IP address that was discovered during the actual vCenter Server install was that of the public facing NIC which we never use for management traffic (it's for internet access on the vC server, for update manager, etc.)
The strange thing is that there had NEVER been an entry in ANY of our DNS servers for that interface. So, after looking into it a little bit, I started thinking the IP that was returned during install was not a DNS result at all. Rather, it was (most likely) simply gathered from the interfaces on the Server based on binding order (e.g. which NIC has the default gateway.)
In order to save having to uninstall and clean up a major mess if the install completed wrong, we stopped and got in touch with VMware support. They suggested we clear all of the temporary files both in the standard "temporary" folder on windows as well as under /ApplicationData/vmware/xxx, where 'xxx' would be whatever product is giving you trouble and HAS NOT been FULLY INSTALLED* (e.g. you started the install and noticed the incorrect IP, so you terminated the installer and there is metadata and cached files remaining from the partially run install).
Basically, what we had to do, was clear the temporary files and then make sure the NIC Binding Priority was correct (so you should check in Network Adapters|(press-alt)|Advanced Settings. Make sure the correct binding is checked (e.g. if you don't use IPv6 on the private network, clear it) and make sure that the Windows Network is at the top of the priority list on the second pane of the advanced settings. This helps tremendously with SSO by making sure the Windows Network stack is the first queried when you are signing in and SSO must submit a kerberos ticket to the AD DC for validation.
It is possible, that once you delete the partial install files and temporary files and fix the network settings (probably be a good idea to reboot as well), the next time you run the installer you might have success.
I will try to check this post later to see if it helped you at all... or it I just succeeded in making your life even more difficult (which I certainly hope not!) :)
One more thing...prior to initializing the installer, open up a PS session, perform ipconfig /flushdns and then ping the hostname of your vCenter server in order to get it in the DNS cache. You should also perform the following:
nslookup
NS>{your vcenter server IP address}
/* make sure the resulting hostname is correct..this ensures your PTRs and rDNS is working correctly. vCenter HEAVILY relies on accurate reverse DNS configuration...then do the following lookup for forward DNS */
NS>{your vcenter server FQDN}
Hope it helps. Best of luck my friend!
SIETEC
I have a bunch of different websites, mostly random weekend projects that I'd like to keep on the web because they are still useful to me. They don't see more than 3-5 hits per day between all of them though, so I don't want to pay for a server for each of them when I could probably fit them all on a single EC2 micro instance. Is that possible? They all run off different web servers, since I tend to experiment with a lot of new tech. I was thinking I could have each webserver serve on a different port, then have incoming requests to app1.com get routed to app1.com:3000 and requests to app2.com get routed to app2.com:3001 and so on, but I don't know how I would go about setting that up.
I would suggest that what you are looking for is a reverse web proxy, which typically includes among its features the ability to understand portions of the request at layer 7, and direct the incoming traffic to the appropriate set of one or more back-end ip/port combinations based on what's observed in the request headers (or other aspects of the request).
Apache, Varnish, and Nginx all have this capacity, as does HAProxy, which is the approach that I use because it seems to be very fast and easy on memory, and thus appropriate for use on a micro instance... but that is not at all to imply that it is somehow more "correct" to use than the others. The principle is the same with any of those choices; only the configuration details are different. One service is listening to port 80, and based on the request, relays it to the appropriate server process by opening up a TCP connection to the appropriate destination, tying the ends of the two pipes together, and otherwise for the most part staying out of the way.
Here's one way (among several alternatives) that this might look in an haproxy config file:
frontend main
bind *:80
use_backend app1svr if { hdr(host) -i app1.example.com }
use_backend app2svr if { hdr(host) -i app2.example.com }
backend app1svr
server app1 127.0.0.1:3001 check inter 5000 rise 1 fall 1
backend app2svr
server app2 127.0.0.1:3002 check inter 5000 rise 1 fall 1
This says listen on port 80 of all local IP addresses; if the "Host" header contains "app1.example.com" (-i means case-insensitive) then use the "app1" backend configuration and send the request to that server; do something similar for app2.example.com. You can also declare a default_backend to use if none of the ACLs match; otherwise, if no match, it will return "503 Service Unavailable," which is what it will also return if the requested back-end isn't currently running.
You can also configure a stats endpoint to show you the current state and traffic stats of your frontends and backends in an HTML table.
Since the browser isn't connecting "directly" to the web server any more, you have to configure and rely on the X-Forwarded-For header inserted into the request headers to identify the browser's IP address, and there are other ways in which your applications may have to take the proxy into account, but this overall concept is exactly how web applications are typically scaled, so I don't see it as a significant drawback.
Note these examples do use "Anonymous ACLs," of which the documentation says:
It is generally not recommended to use this construct because it's a lot easier
to leave errors in the configuration when written that way. However, for very
simple rules matching only one source IP address for instance, it can make more
sense to use them than to declare ACLs with random names.
— http://cbonte.github.io/haproxy-dconv/configuration-1.4.html
For simple rules like these, this construct makes more sense to me than explicitly declaring an ACL and then later using that ACL to cause the action that you want, because it puts everything together on the same line.
I use this to solve a different root problem that has the same symptoms -- multiple sites for development/test projects, but only one possible external IP address (which by definition means "port 80" can only go to one place). This allows me to "host" development and test projects on different ports and platforms, all behind the single external IP of my home DSL line. The only difference in my case is that the different sites are sometimes on the same machine as the haproxy and other times they're not, but the application seems otherwise identical.
Rerouting in way you show - depends on the OS your server is hosting on. For linux you have to use iptables, for windows you could use windows firewall. You should set all incoming connections to a port 80 to be redirected do desired port 3000
But, instead of port, you could use a different host name for each service, like
app1.apps.com
app2.apps.com
and so on. You can configure it with redirecting on your DNS hosting, for apps.com IMHO this is best solution, if i got you right.
Also, you can configure a single host to reroute to all other sites, like
app1.com:3001 -> apphost1.com
app1.com:3002 -> apphost2.com
Take in mind, in this case, all traffic will pas through app1.com.
You can easily do this. Set up a different hostname for each app you want to use, create a DNS entry that points to your micro instance, and create a name-based virtual host entry for each app.
Each virtual host entry should look something like:
<VirtualHost *>
ServerName app1.example.com
DocumentRoot /var/www/html/app1/
DirectoryIndex index.html
</VirtualHost>