All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Any Apache Wizard ?
I have searched the internet(go away lmgtfy advocates) and found no help in this.
What I am trying to do is reverse proxy to a subdomain like this (not working)
ProxyPreserveHost On
>
ProxyPass "/" "http://sub.domain.sometld"
>
ProxyPassReverse "/" "http://sub.domain.sometld"
When I visit this url "http://sub.domain.sometld" directly, it issues a redirect to an ipv4.
If I use this ipv4 directly like below the reverse proxy works perfectly well.
ProxyPass "/" "http://xxx.xxx.xxx.xxx"
>
ProxyPassReverse "/" "http://xxx.xxx.xxx.xxx"
But since this ipv4 keeps on changing periodically, I need to use the hostname instead.
so far, I have failed in all my tries, I know I can do this by writing an externally script run by cron which queries the subdomain's ip periodically and makes changes in the virtual host file + restarting apache every time but it all just seems very wrong, a massive overkill !
Shouldn't there be a simple way of doing this ?
Comments
Use nginx
Maybe the software installed on http://sub.domain.sometld is making the redirection, e.g. Wordpress
In general I agree with @OpticalSwoosh
But that does not answer the question.
@raza19 What are you actually trying to achieve, what makes you think that it does not work and what is the configuration of the subdomain? Is the subdomain redirecting to the IP it does resolve to?
Apart from configuration. Do you have access to subdomain's configuration? You probably want to use DNS' CNAME entry for what you are trying to achieve.
@TWo
Basically its a dvr setup and each camera comes with a built in url/subdomain from the manufacturer. The camera tells the manufacturer its current ip and they update the subdomain to redirect( & no its not ddns but kinda like it).
So, what I am trying to do is create a reverse proxy on a vps pointing to the manufacturer's subdomain.
Why do I need to do this when I can directly access the camera using manufacturer's subdomain ? Because most of the apps/software available today that are used to access dvr feeds don't take in to account url redirects, they only work when I feed in a status 200 url.
But if I can manage to use a static vpn ip which in the background reverse proxies to the changing ip of the manufacturer's subdomain then I can use all the apps/software.
and how does it issue this redirect?
if it does so by header redirect the browser simply leaves your proxy and connects to the real destination. yet you probably would need to know the IP the redirect is going to beforehand to may be able to rewrite headers on the way out.
I'd say monitoring the IP via an external script and updating the vhost is by far the simpliest solution.
302
What I am trying to avoid.
So you have no control over that subdomain's HTTPD, right?
Based on what you write in the OP a reverse proxy to the subdomain won't help you then as it will always return a redirect to the plain IP address.
With plain HTTPD I see no way then. Instead of having a cron, you can write a script which accesses the subdomain, inspects the Location header and then retrieves and streams content from that location. Depending on the complexity of that page this might work acceptable. But agreeing with @Falzo - updating the vhost is far more simpler.
The better solution would be to get a proper working webcam. WTH they do HTTP Redirect instead of DDNS? What happens if they manage to not renew their domain?
Sadly the white man killed all the apache so no more apache wizards left :-(
Packing for a trip and not reading.. so anyhow. I would use nginx not Apache for this, I think you will have a lot better of a time.
my 2 cents.
Cheers!
your ProxyPassReverse directive simply parses headers for your subdomain on the way out. therefore a header with an IP instead wont get rewritten.
you would need further directives for that and actually I don't know of any (internal) way how apache should recognize this redirect, determine the correct IP from it and add additional proxy rules for this to itself...
there are some articles through the web which suggest something like adding a custom path to your url via rewrite, which you can later determine and rewrite back. like tagging on the way in and check on the way out, but I have never tried something like that and suppose you don't have access to the server you are trying to proxy...
as said, a small script monitoring for ip changes and updating the proxy rules should not only be easier, probably it will be the only choice.
debian thx
nginx thx
Your nginx rants are not helpful. Although it is superior to Apache it faces the same problem of a BS implementation of the webcam's vendor.
@TheLinuxBug pointed out a nice solution:
Instead of using subdomain.vendor.domain you can use subdomain.yourown.domain and then DDNS update your own subdomain with the correct IP address. Then you only need regular checks on the IP in the Location response header of subdomain.vendor.domain.
A lot of DDNS services allow updating to custom IP, e.g. Namecheap
Or you delegate the NS for one of you subdomains to your VPS and run your own DDNS there (for sub.sub.domain.tld). In that scenario you could even drop the cron'd script but "resolve" on every DNS query.
I guess that won't help with the vendor doing a 302 redirect to a plain IP as URL either...
The problem with setting up my own ddns is the downtime that comes as a result of cached values, even if I give the lowest ttl for the subdomain I set up to point towards the ip, dnservers force their own cached timings.
However, the reverse proxy approach will instantly change to the new ip in the background. @Falzo is right.
I have read the new apache 2.4 IF statements and they might do the job but it's turning to an overkill!
The new versions of cli php do come with a built in server and there might be a way to use the stream wrapper but again it seems like an overkill.
I'm going to stick with modifying the vhost for now.
Thank you everyone for taking the time to respond.
@Falzo: You don't get me.
1) Get webcam's IP (e.g. via cron)
$ curl -v "http://webcam23581321.vendor.cn/" < HTTP/1.1 302 Moved Permanently < Location: http://23.58.13.21/2) Set own DNS A record via DDNS
$ curl "https://dynamicdns.park-your-domain.com/update?host=mywebcam1&domain=raza19.xyz&password=HASH&ip=23.58.13.21"3) Access webcam via http://mywebcam1.raza19.xyz/
Other option is to delegate NS for *.webcams.raza19.xyz to IP of raza19's VPS and have a fake DNS server running there which performs these steps for a query like
webcam23581321.webcams.raza19.xyz. IN Awebcam23581321.webcams.raza19.xyz. 60 IN A 23.58.13.21Then one can access the webcam via http://webcam23581321.webcams.raza19.xyz/
Unfortunately both suggestions do not involve Apache nor Nginx.
That's why I've asked what he wants to achieve as I'd anticipated a XY problem.
Yes, this will work but like I said earlier this has a flaw of possible outdated cached values. When I ask for ip of webcam23581321.webcams.raza19.xyz from Google's dns, they will store the ip for a certain time and if the ip changes during that time, another request for the address will return a stale ip until Google decides to check for the ip again.
The reverse proxy method however does not have this issue though it will consume resources but I have plenty of vps to spare.
Nevertheless, Thank you for the explanation .
oh, I think I got your idea before, and it sounds good but I think if the vendor simply redirects requests to a plain IP as in
using the updated ddns subdomain like
will most probably give the same result:
and yet that redirect is what @raza19 wants to get rid of...
@raza19 Google's Public DNS honors TTL. Just set the TTL to 60 which is a minute (as in the given example). You probably won't get faster updates with a cron'd script as most cron's resolution is a minute, while you can decrease TTL down to one second. There's a "Thanks" link and its usage is highly appreciated.
@Falzo: No you still don't get the idea. mywebcam1.raza19.xyz already resolves to 23.58.13.21 or are you implying the webcam's httpd is that broken that it does not accept any "Host" header and redirects to itself when seeing one? Given that webcam even knows its own IP.
I wonder how do you recognize IP change? When streaming stops? Will your DVR try to reconnect at once? Then DNS solution brings requests to vendor down from 1440/day to 1/day.
you are right, I've somewhat overseen the part that the webcam itself is the second httpd where it's got redirected to.
but from what @raza19 told above the webcam has to know or at least has to determine its own IP, as it somehow tells it to the vendor who does the redirect...
and as you said:
If you want to produce an unknown number of such cams for cheap you would not want to program everything into each camera individually. software must be as simple and uniform as possible across all units.
so the cam knows a way to determine an ip and probably got a serialnumber. this may suffice to identify the unit to the vendor and he sets up a redirect on that subdomain. he could even change domain/subdomain as long as he informs the customer in any way...
after all I'd say it may be not so far away that the cam wont accept anything but the IP ;-)
The cam most probably does not know its own external (public) IP. Think of a phone you don't know the number of. You call another phone to get that number.
That's what these cheap cams normally do, they call home.
curl http://discovery.vendor.cn/?serial=0x1234567890The happy buyer of the cam visits http://register.vendor.cn, enters serial chooses a subdomain and the vendor associates the subdomain with the serial. So whenever the cam now calls home, the vendor updates subdomain to point to that IP.
For the cam it makes no difference how the vendor discloses its IP to the buyer. For about two decades DDNS has been the proper way to do it. But if you are low on budget you cannot afford a proper engineering team with experience. So that team has never heard about DDNS nor was looking at how competitors do it. That's when you re-invent the whell but make it worse. This vendor here most probably uses Apache with PHP_MOD and what happens behind the scene is that a PHP querys a MySQL DB with $_SERVER['HTTP_HOST'] to retrieve IP and outputs Location header. The same could be achieved with a DNS server. It would use less ressources and less bandwith.
Vendor cannot discontinue domain. Cam won't be able to call home anymore. Because of low budget vendor hasn't prepared a way to update the call home URL. Interesting Read
I'm very sure cam does not inspect "Host" header as this would involve additional engineer which would have cost money.
PS: A decade ago when I bought the last IP Cam, it came with an admin interface where you had to configure the DDNS client (after choosing one of the dozens of DDNS services around) - no low end vendor was even thinking about dealing to provide such service. But nowadays the cost of operating such service is lower than delivering a proper manual and forcing the customer to understand what happens. And if you want to sell another batch of your cams you just discontinue your service (vendor lock in) ;*)