I was checking out my production.log on my server and sees these lines comes every time the code is suspected to read or write cache:
DalliError: No server available
Write fragment views/artists/522-...
DalliError: No server available
Read fragment views/artists/92-...
Why and is that something i need to be worried about?
Im using dalli (2.6.2), cache_digests (0.2.0), rails (3.2.11) and memcached (1.4.2).
When I installed memcached, I happened to use sudo, can that have something to do with it?
That was probably related to the fact that Dalli was defaulting to localhost
It's solved since 2.6.4 - https://github.com/mperham/dalli/pull/266
Related
I am trying to understand/reproduce Log4shell vulnerability, using this poc and also information from Marshalsec.
To do that, I've downloaded Ghidra v10.0.4, which is said (on Ghidra download page) to be vulnerable to log4shell. Installed it on an ubuntu VM, along with java 1.8 (as stated in POC), and loaded the Poc + marshalsec snapshot.
Tried to start Ghidra, it said java 11 was needed, so although I've installed java 1.8 I still downloaded java 11 and, when you start ghidra, it says the installed version is not good enough and ask for the path to a java11 version; so I just gave him path to the jdk11 directory and it seems happy with it. Ghidra starts alright.
Then set up my listener and launched the poc, got the payload string to copy/paste in ghidra, and got a response in the ldap listener saying it'll send it to HTTP. But nothing more. The end.
Since the HTTP server is set up by the same POC, I thought maybe I just couldn't see the redirection, so I started the http server myself, started the ldap server myself with marshalsec, and retried (see pics below for exact commands/outputs).
Setting http server:
Set listener:
Setting LDAP server:
Send payload string in Ghidra (in the help/search part, as shown in kozmer POC); immediately got an answer:
I still receive a response on the LDAP listener (two, in fact, which seems weird), but nothing on the HTTP. The the Exploit class is never loaded in ghidra (it directly sends me a pop-up saying search not found, I think it is supposed to wait for the server answer to do that?), and I get nothing back in my listener.
Note that I don't really understand this Marshalsec/LDAP thing so I'm not sure what's happening here. If anyone have time to explain it will be nice. I've read lot of stuff about the vuln but it rarely goes deeply into details (most is like: the payload string send a request to LDAP server, which redirect to HTTP server, which will upload the Exploit class on the vulnerable app and gives you a shell).
Note: I've checked, the http server is up and accessible, the Exploit.class file is here and can be downloaded.
Solved it.
Turned out for log4shell to work you need a vulnerable app and a vulnerable version of Java; which I thought I had, but nope. I had Java 11.0.15, and needed Java 11 (Ghidra need Java 11 minimum, only vulnerable version of Java 11 is the first one).
Downloaded and installed Java 11, POC working perfectly.
I have scoured the Internet without finding an adequate solution, so I'm here to ask the SO community for help.
I'm migrating a rails 2 app on Heroku Bamboo to Cedar. Concomitantly, I am moving to rails 3 and ruby 2.0.0 (though I get this error with ruby 1.9.3 as well).
It seems that MongoMapper has undergone a bit a change from 0.8.6, to the point where I can't use our old initializer anymore. I'm attempting to use the latest 0.13.1 version of mongo_mapper.
According to https://devcenter.heroku.com/articles/mongohq, I just need to set config/mongo.yml to:
production:
uri: <%= ENV['MONGOHQ_URL'] %>
and I'm all set (I also commented out the old initializer code). However, it fails with the following connection error:
Feb 05 11:18:28 my-app-name app/web.1: /app/vendor/ruby-2.0.0/lib/ruby/2.0.0/uri/generic.rb:214:in `initialize': the scheme mongodb does not accept registry part: heroku:2QMdYzo6z5nmJJsmWAWKd_205umc05tBuP2ZodGaNDZ7N5rE4ns09jhsfFBjmkQ2ls_rfTiVC0lD24Y2byDXbg#candidate.21.mongolayer.com:10499,candidate.4.mongolayer.com:10625 (or bad hostname?) (URI::InvalidURIError)
An invalid URI is understandable, but that's what being fed to me by Heroku. What do I am missing in order to for the uri parser to accept it?
Thank you in advance.
The answer lies in the presence of that comma (,) in the uri. When I removed the second host and the comma, it behaved correctly :-)
Specifically, I created a Heroku ENV variable called MONGOHQ_URL2 without the second host name, then updated my config/mongo.yml to use that one instead.
In the configuration file example for Puma, it says the following for the on_restart function:
Code to run before doing a restart. This code should close log files,
database connections, etc.
Do I need to implement this for a Rails app, to close connections to the db and the logfile, or is that taken care of automatically? If not, how do I actually do all that?
No you don't, Rails takes care of reloading your code automatically. But this code reloading support is limited. For example changes to application.rb are not applied until you restart the app server.
But I would recommend Phusion Passenger over Puma. Phusion Passenger is a lot easier to setup, especially when you hit production. Phusion Passenger integrates into Apache and Nginx directly and provides advanced features like dynamic worker management. Phusion Passenger is very mature, stable and performant and used by the likes of New York Times, Symantec, AirBnB, etc.
I've found that using Redis as my Rails.cache provider causes an error page upon the first request every time my Rails/Puma server is restarted. The error I got was:
Redis::InheritedError (Tried to use a connection from a child process
without reconnecting. You need to reconnect to Redis after forking.)
To get around this error, I didn't add anything to on_restart, but did have to add code to on_worker_boot ( I am running Puma with workers=4 ):
puma-config.rb
on_worker_boot do
puts "Reconnecting Rails.cache"
Rails.cache.reconnect
end
I'm using Rails 3.0.5 version and Ruby 1.9.2 in my application.
Its working fine in development mode but in production mode server goes down after every 3-4 days.
It gives below error in /var/log/https/error.log file.
[Sun Oct 21 09:39:03 2012] [error] [IP_ADDRESS] **Premature end of script headers:**
[ pid=24971 thr=1 file=ext/apache2/Hooks.cpp:817 time=2012-10-21 09:39:03.371 ]:
The backed application (process 29805) did not send a valid HTTP response; instead, it sent nothing at all. It is possible that it has crashed; please check whether there are crashing bugs in this application.
I am not getting what's the reason for server down.
which server your using? webrick or else? i got some problem like this in past that server goes down. i changed server from webrick to Mongrel its faster then webrick
Sorry i can't comment so answering, personally haven't come across this problem but there seems to be quite some talk about it. Here are a few resources that i came across:
Dalibor Nasevic's explanation as to why this is happening
Premature end of script headers — Rails
Intermittent “premature end of script headers” with Rails 3.1
Hope it helps.
I am getting a 404 error when trying to push my database to Heroku via Taps
(1.9.2#[app_name]_db) heroku db:push --app [app_name]
Loaded Taps v0.3.24
Auto-detected local database: sqlite://db/development.sqlite3
Warning: Data in the app '[app-name]' will be overwritten and will not be recoverable.
! WARNING: Destructive Action
! This command will affect the app: [app-name]
! To proceed, type "[app-name]" or re-run this command with --confirm [app-name]
> [app-name]
Sending schema
Schema: 0% | | ETA: --:--:--
Saving session to push_201209251425.dat..
!!! Caught Server Exception
HTTP CODE: 404
The db:push command used to work fine, then I made some changes to my database by rolling back the migrations, editing them, and then re-migrating. Now I can deploy the app just fine, but the database will not push -- I don't know if this is related to editing the migrations or not.
The app works fine on my machine, and I wanted to eliminate any discrepancies between Heroku's copy and my own, so I created a new app and pushed to that. Same thing: the Heroku app works but will not receive db:push; it errors out with the same 404 above.
Is this a Heroku service temporarily down, or has changing my app caused the 404?
Edit: heroku logs do not show any error message
Heroku support was taking too long to respond, so I found a workaround that communicates with my EC2 instance directly by using the Taps gem.
Go to Heroku dashboard for your database. For me this was at
https://postgres.heroku.com/databases/[my-database-name]
though I navigated by going through Addons.
Click on 'URL' in 'Connection Settings', should give you something like
postgres://[username]:[password]#ec2-[ip_address_numbers].compute-1.amazonaws.com:[port]/[database_name]
Copy this value down, I'll reference it here as [EC2_URL]
Get Taps installed on 1.9.2 gemset if you don't already have it (not sure if 1.9.3 will work, didn't test it)
Set up localhost taps server to facilitate transaction by running in terminal:
taps server postgres://[local_machine_username]#localhost/[name_from_database.yml] [some_username] [some_password]
(note the spaces before username and password)
Then you can process the transaction yourself through another terminal window:
taps pull [EC2_URL] http://[some_username]:[some_password]#localhost:5000
It should run and pull all your data from the local development db to the Amazon instance. You can also do vice versa, or choose a different database, etc. Or not, I'm not a cop.
There are some problems with heroku db commands and ruby 1.9.2 (I have this version).
db:pull ends with "Unable to fetch tables information from"
db:push ends with "!!! Caught Server Exception HTTP CODE: 404"
There is a work-around for this problem. Switch to ruby 1.8.7 (I am using rvm for this) for a moment just to do db operations on heroku and after finish switch ruby back.
I do the same process (have Heroku convert my sqlite database to Postgres), and I was getting this problem yesterday as well. It seems to be working now, so I'm believe it was an issue with Heroku.