i've my local repo which serve my serves , strange thing , ive added new package ( update for old version )
when ever i try to update i always get No Packages marked for Update
here is my base repo config
[base]
name=CentOS-$releasever - Base
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
baseurl=http://CentOS/centos/$releasever/os/$basearch/
gpgcheck=0
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
[updates]
name=CentOS-$releasever - Updates
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
baseurl=http://CentOS/centos/$releasever/updates/$basearch/
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
As Edition :
curl -I http://CentOS/
HTTP/1.1 200 OK
Date: Sun, 28 Sep 2014 07:41:03 GMT
Server: Apache/2.2.15 (CentOS)
Last-Modified: Mon, 11 Feb 2013 08:48:56 GMT
ETag: "148211-5-4d56efab30e00"
Accept-Ranges: bytes
Content-Length: 5
Connection: close
Content-Type: text/html; charset=UTF-8
Please advise do i miss anything make my yum server not picking updated packages ?
You may need to rerun createrepo on your local server, or run
yum clean all
on your client.
Related
We have a vendor who sends us photos that are hosted on Azure Edge. These photos are available and I can download them, but if we do a CURL request we get a 404 roughly 4 out of 5 times. If we do a HEAD request to get the filesize, we get a 404 about 7 out of 10 times. On our production server, we get a 404 100% of the time. Any idea how we might work around this or if there's another way to check these files without the vendor having to fix their issue?
Sample file:
curl -I http://tdrvehicles2.azureedge.net/photos/202008/1419/1850/f253435f-86b1-4cc4-b95c-7756addddad4.jpg
HTTP/1.1 404 Not Found
Pragma: no-cache
Content-Length: 0
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Cache-Control: max-age=31536000
Expires: Thu, 19 Aug 2021 14:12:54 GMT
Date: Wed, 19 Aug 2020 14:12:54 GMT
Connection: keep-alive```
I have excluded the url like this from my varnish cache
if (req.url ~ "^/folder_name/") {
return (pass);
}
but still when i access curl -I http://ip/folder_name i see the below response
HTTP/1.1 301 Moved Permanently
Date: Mon, 04 Jul 2016 08:48:46 GMT
Server: Apache/2.2.15 (CentOS)
Location: http://ip/folder_name/
Content-Length: 319
Content-Type: text/html; charset=iso-8859-1
X-Varnish: 294958
Age: 0
Via: 1.1 varnish-v4
Connection: keep-alive
Can anyone please tell me what am i doing wrong, i need to exclude
"all urls that start with /folder_name" from being cached in varnisg
Your regex ends in a slash and "http://ip/folder_name does" not - could this be it?
I use Privoxy or Proxomitron to inject custom Javascript tags into websites which then load scripts from a local python server (on localhost:8888):
... <script type="text/javascript"
src="http://localhost:8888/tweakscript.js"
></script></body>
Some of these script tags are huge third party javascript libraries which are also stored on my computer. They never change but are reloaded each time. I want to cache them.
i tried these headers, without success:
HTTP/1.1 200 OK
Content-type: text/javascript; charset=UTF-8
Vary: Accept-Encoding
Date: Sun, 04 Oct 2015 03:24:14 GMT # the current date
Last-Modified: Fri, 02 Oct 2015 06:34:40 GMT # never changes
Expires: Fri, 01 Apr 2016 03:24:14 GMT # one month in future
Cache-Control: public, max-age=15552000 # cache for one year
Access-Control-Allow-Origin: * # Content Security Policy
Access-Control-Allow-Methods: GET, POST, OPTIONS
Connection: close
(javascript code here)
How can i make the webbrowser cache these files?
OK, i found the solution:
When requesting files, the browser adds an If-Modified-Since request header, eg:
If-Modified-Since: Tue, 28 Jul 2015 22:48:42 GMT
If the server then sends as response ...
HTTP/1.1 304 Not Modified
... then the browser will load the file from cache.
I got that error when trying to use cabal update
below were the results of cabal update -v3
Downloading the latest package list from hackage.haskell.org
Sending:
GET /packages/archive/00-index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/1.16.0.2
Creating new connection to hackage.haskell.org
Received:
HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.2
Date: Thu, 13 Nov 2014 00:14:21 GMT
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Location: /packages/index.tar.gz
Content-Length: 0
301 - redirect
Redirecting to http://hackage.haskell.org/packages/index.tar.gz ...
Sending:
GET /packages/index.tar.gz HTTP/1.1
Host: hackage.haskell.org
User-Agent: cabal-install/1.16.0.2
Recovering connection to hackage.haskell.org
Received:
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Thu, 13 Nov 2014 00:14:21 GMT
Content-Type: application/x-gzip
Content-Length: 8090775
Connection: keep-alive
Content-MD5: bae2f93619ba845eff2f3bd544714c2c
ETag: "bae2f93619ba845eff2f3bd544714c2c"
Last-Modified: Wed, 12 Nov 2014 23:04:10 GMT
Downloaded to /root/.cabal/packages/hackage.haskell.org/00-index.tar.gz
Updating the index cache file...
cabal update: /usr/hs/tools/cabal-1.16.0.2 failure (return code=-9)
haskell was installed from justhub
Does anyone have any idea why it failed? I looked for the return code of -9 but there's no information.
Update
Thanks Reid (and user5402),
Checked the dmesg and that's definitely because it's out of memory
Out of memory: Kill process 32626 (cabal-1.16.0.2) score 711 or sacrifice child
Will upgrade the machine and try again, not sure how much would cabal-install need though, I'm on a 512MB RAM system
The value -9 probably means a child process died to SIGKILL, which in turn was probably sent by the OOM killer. Checking the output of dmesg can confirm this. If that's the case, one needs to turn up the RAM available. (based on this comment).
512Mb of RAM is not enough. Instead of upgrading machine you can enable swap.
On ubuntu do following steps:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
It will add you 4G swap file, that will prevent killing from OS.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
The community reviewed whether to reopen this question 8 months ago and left it closed:
Original close reason(s) were not resolved
I have a problem with my server redirecting http://www.mylesgray.com:8080/ -> http://www.mylesgray.com/.
Here are my Nginx default and fastcgi_params config files:
https://gist.github.com/1745271
https://gist.github.com/1745313
This is rather a nusance as I am trying to run a benchmark of Nginx w/ caching vs Varnish w/ caching on top of Nginx to see if there is any performance benefit of one over the other.
As such I have straight Nginx w/ caching listening on port 8080 and varnish on port 80 which forwards any non-cached requests to Nginx on localhost:8080, so obviously what I want to do is run an ab benchmark on http://www.mylesgray.com:8080/ and on http://www.mylesgray.com/ to see the difference.
Here are the results of curl -I on various addresses.
# curl -I http://www.mylesgray.com:8080
HTTP/1.1 301 Moved Permanently
Server: nginx/0.7.65
Date: Sun, 05 Feb 2012 12:07:34 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.3.2-1ubuntu4.7ppa5~lucid1
X-Pingback: http://www.mylesgray.com/xmlrpc.php
Location: http://www.mylesgray.com/
# curl -I http://mylesgray.com
HTTP/1.1 301 Moved Permanently
Server: nginx/0.7.65
Content-Type: text/html; charset=UTF-8
X-Powered-By: PHP/5.3.2-1ubuntu4.7ppa5~lucid1
X-Pingback: http://www.mylesgray.com/xmlrpc.php
Location: http://www.mylesgray.com/
Content-Length: 0
Date: Sun, 05 Feb 2012 12:15:51 GMT
X-Varnish: 1419774165 1419774163
Age: 15
Via: 1.1 varnish
Connection: keep-alive
# curl -I http://mylesgray.com:8080
HTTP/1.1 301 Moved Permanently
Server: nginx/0.7.65
Date: Sun, 05 Feb 2012 12:16:08 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.3.2-1ubuntu4.7ppa5~lucid1
X-Pingback: http://www.mylesgray.com/xmlrpc.php
Location: http://www.mylesgray.com/
Then running curl -I http://www.mylesgray.com gives:
# curl -I http://www.mylesgray.com
HTTP/1.1 200 OK
Server: nginx/0.7.65
Content-Type: text/html; charset=UTF-8
X-Powered-By: PHP/5.3.2-1ubuntu4.7ppa5~lucid1
X-Pingback: http://www.mylesgray.com/xmlrpc.php
Content-Length: 5132
Date: Sun, 05 Feb 2012 12:07:29 GMT
X-Varnish: 1419774133 1419774124
Age: 30
Via: 1.1 varnish
Connection: keep-alive
So as you can see 80 is served by Varnish and 8080 by Nginx but I cannot find anywhere anything that does a 301 redirect, not in nginx.conf or in the sites-enabled/default file and I don't believe it is caused by Wordpress itself but an very much open to correction.
Please help, this is driving me nuts!
Myles
You should add a '/' at then end of your URLs. Furthermore if you run ab http://foo.com it will return you a "ab: invalid URL" error. If you do "ab -t 10 http://example.com/" everything will work fine. You should always use '/' in your URLs otherwize your webserver will try to redirect the page to the home page automatically for you which generates an undesirable extra load on the server and some extra bytes on the wire.
You web server told you what it did:
'/' is missing and something is incorrect with the port numer:
# curl -I http://www.mylesgray.com:8080
HTTP/1.1 301 Moved Permanently
[...]
======> Location: http://www.mylesgray.com/
'www' and '/' are missing:
# curl -I http://mylesgray.com
HTTP/1.1 301 Moved Permanently
[...]
=======> Location: http://www.mylesgray.com/
[...]
'/' and 'www' are missing:
# curl -I http://mylesgray.com:8080
HTTP/1.1 301 Moved Permanently
[...]
========> Location: http://www.mylesgray.com/
'hope that helps :)
The presence of an X-Powered-By: PHP header means that wordpress is issuing the 301. It's due to wordpress forcing www.mylesgray.com. When you use a nonstandard port, user agents will generally include the port in the Host: header. Try adding
fastcgi_param HTTP_HOST $host;
with the rest of your fastcgi_param directives (or alog with your "include fastcgi_params;") and it should fix this.