did you try to update the gems and also reinstall pg ????
it looks like the pg gem is corrupt or outdated
r083rt
Just ran msfupdate and now trying to run this command 'search netapi' now getting a different output:
what's the story with you guys..Code:msf > search netapi [-] Error while running command search: PG::Error: ERROR: column "module_details.mtime" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: SELECT DISTINCT(module_details.*) FROM "module_details" LEFT... ^ : SELECT DISTINCT(module_details.*) FROM "module_details" LEFT OUTER JOIN module_authors ON module_details.id = module_authors.module_detail_id LEFT OUTER JOIN module_actions ON module_details.id = module_actions.module_detail_id LEFT OUTER JOIN module_archs ON module_details.id = module_archs.module_detail_id LEFT OUTER JOIN module_refs ON module_details.id = module_refs.module_detail_id LEFT OUTER JOIN module_targets ON module_details.id = module_targets.module_detail_id LEFT OUTER JOIN module_platforms ON module_details.id = module_platforms.module_detail_id WHERE ( ( module_details.fullname ILIKE '%netapi%' OR module_details.name ILIKE '%netapi%' OR module_details.description ILIKE '%netapi%' OR module_authors.name ILIKE '%netapi%' OR module_actions.name ILIKE '%netapi%' OR module_archs.name ILIKE '%netapi%' OR module_targets.name ILIKE '%netapi%' OR module_platforms.name ILIKE '%netapi%' ) ) GROUP BY module_details.id Call stack: /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:1139:in `async_exec' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:1139:in `exec_no_cache' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:663:in `block in exec_query' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/abstract_adapter.rb:280:in `block in log' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activesupport-3.2.2/lib/active_support/notifications/instrumenter.rb:20:in `instrument' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/abstract_adapter.rb:275:in `log' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:662:in `exec_query' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:1234:in `select' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/abstract/database_statements.rb:18:in `select_all' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/abstract/query_cache.rb:63:in `select_all' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/querying.rb:38:in `block in find_by_sql' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/explain.rb:25:in `logging_query_plan' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/querying.rb:37:in `find_by_sql' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/relation.rb:171:in `exec_queries' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/relation.rb:160:in `block in to_a' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/explain.rb:25:in `logging_query_plan' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/relation.rb:159:in `to_a' /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/relation/finder_methods.rb:159:in `all' /opt/metasploit/msf3/lib/msf/core/db_manager.rb:579:in `block in search_modules' /opt/metasploit/msf3/lib/msf/core/patches/active_record.rb:22:in `with_connection' /opt/metasploit/msf3/lib/msf/core/db_manager.rb:531:in `search_modules' /opt/metasploit/msf3/lib/msf/ui/console/command_dispatcher/core.rb:1369:in `search_modules_sql' /opt/metasploit/msf3/lib/msf/ui/console/command_dispatcher/core.rb:1338:in `cmd_search' /opt/metasploit/msf3/lib/rex/ui/text/dispatcher_shell.rb:420:in `run_command' /opt/metasploit/msf3/lib/rex/ui/text/dispatcher_shell.rb:382:in `block in run_single' /opt/metasploit/msf3/lib/rex/ui/text/dispatcher_shell.rb:376:in `each' /opt/metasploit/msf3/lib/rex/ui/text/dispatcher_shell.rb:376:in `run_single' /opt/metasploit/msf3/lib/rex/ui/text/shell.rb:200:in `run' /opt/metasploit/msf3/msfconsole:143:in `<main>' msf >
did you try to update the gems and also reinstall pg ????
it looks like the pg gem is corrupt or outdated
r083rt
Does it work for built-in pg of metasploit as well?
btw, why do we need a seperate postgresql for metasploit? Wouldn't it better if metasploit uses installed postgresql and requires it as a dependence? It creates confusion, I think. I experienced 2 major problems addressing postgresql connection of msf in past 2 days. I've just started to use linux, but I see even experienced users are having trouble using it.
Could you elaborate on this please?
Im not sure what backtrack uses i.e if they have ruby 1.9.3 or still using 1.9.2 [ 1.9.2 is much slower at loading modules ]
anyway ..
if the database is corrupt remove it and create a new database and restart postgresCode:gem install rubygems-update gem update-system gem update gem uninstall pg gem cleanup all gem install pg msfupdate
r083t
Well, I had same problem. I found a working way but i m not sure about whether it lose some functionality.
1) Open /opt/metasploit/msf3/lib/msf/core/db_manager.rb (I advise you to backup it before you change)
2) Go to line 592, delete the dot at end of line
3) Delete line 593
4) Reopen msfconsole
Here is diff:
The problem is about semantics of GROUP BY clause in PostgreSQL, I guess. It would be great if somebody who hasn't this problem would share these lines with us.Code:root@bt:/opt/metasploit/msf3/lib/msf/core# diff db_manager.rb db_manager.rb-backup 592c592,593 < where(where_q.join(inclusive ? " OR " : " AND "), *(where_v.flatten)) --- > where(where_q.join(inclusive ? " OR " : " AND "), *(where_v.flatten)). > group("module_details.id, module_details.*") root@bt:/opt/metasploit/msf3/lib/msf/core#
what I do not understand why do we need to separately update gems and reinstall pg. Should not msfupdate take care of it.
Here is my ruby version:
root@bt:~# ruby --version
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
My current search output:
Surely this error must be widespread.. I think jury is still out..Code:=[ metasploit v4.4.0-dev [core:4.4 api:1.0] + -- --=[ 898 exploits - 486 auxiliary - 150 post + -- --=[ 251 payloads - 28 encoders - 8 nops =[ svn r15591 updated today (2012.07.08) msf > search netapi [-] Error while running command search: PG::Error: ERROR: column "module_details.mtime" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: SELECT DISTINCT(module_details.*) FROM "module_details" LEFT... ^ : SELECT DISTINCT(module_details.*) FROM "module_details" LEFT OUTER JOIN module_authors ON module_details.id = module_authors.module_detail_id LEFT OUTER JOIN module_actions ON module_details.id = module_actions.module_detail_id LEFT OUTER JOIN module_archs ON module_details.id = module_archs.module_detail_id LEFT OUTER JOIN module_refs ON module_details.id = module_refs.module_detail_id LEFT OUTER JOIN module_targets ON module_details.id = module_targets.module_detail_id LEFT OUTER JOIN module_platforms ON module_details.id = module_platforms.module_detail_id WHERE ( ( module_details.fullname ILIKE '%netapi%' OR module_details.name ILIKE '%netapi%' OR module_details.description ILIKE '%netapi%' OR module_authors.name ILIKE '%netapi%' OR module_actions.name ILIKE '%netapi%' OR module_archs.name ILIKE '%netapi%' OR module_targets.name ILIKE '%netapi%' OR module_platforms.name ILIKE '%netapi%' ) ) GROUP BY module_details.id, module_details.* Call stack: /opt/metasploit/msf3/lib/gemcache/ruby/1.9.1/gems/activerecord-3.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:1139:in `async_exec'
I also looked into this issue and I agree it's a problem with the change to the GROUP BY clause in the /opt/metasploit/msf3/lib/msf/core/db_manager.rb file.
The problem is cause by the use of the wildcard in the GROUP By clause. This is not a valid operation in Postgres 8.4 it was brought in in version 9.1. This is why taking out the line: group("module_details.id, module_details.*") fixes the issue.
A possibly better fix would be to fix the GROUP BY clause in a way that works with Postgres 8.4 and 9.1 yet still makes the query work as the developers intended. If you change the end of the function to the following you'll be back in action in no time:
Hope this helps someone out and saves you a bit of time.Code:qry = Mdm::ModuleDetail.select("DISTINCT(module_details.*)"). joins( "LEFT OUTER JOIN module_authors ON module_details.id = module_authors.module_detail_id " + "LEFT OUTER JOIN module_actions ON module_details.id = module_actions.module_detail_id " + "LEFT OUTER JOIN module_archs ON module_details.id = module_archs.module_detail_id " + "LEFT OUTER JOIN module_refs ON module_details.id = module_refs.module_detail_id " + "LEFT OUTER JOIN module_targets ON module_details.id = module_targets.module_detail_id " + "LEFT OUTER JOIN module_platforms ON module_details.id = module_platforms.module_detail_id " ). where(where_q.join(inclusive ? " OR " : " AND "), *(where_v.flatten)). # This doesn't work in Postgres 9.4 # group("module_details.id, module_details.*") # Compatibility for Postgres installations prior to 9.1 - 8.4 doesn't have support for wildcard group by clauses group("module_details.id, module_details.mtime, module_details.file, module_details.mtype, module_details.refname, module_details.fullname, module_details.name, module_details.rank, module_details.description, module_details.license, module_details.privileged, module_details.disclosure_date, module_details.default_target, module_details.default_action, module_details.stance, module_details.ready") res = qry.all }
Alternatively, updating Postgres to 9.1 will get id of the problem entirely. When I get a bit of time I am going to separate out the postgres dependecy on my machine so that Metasploit connects to that instead of the version shipped with Metasploit this will remove one dependency from the chain.
Cheers,
Patrick
Ditto here,
First the search wasn't working for exploits, then after "svn up," I get the database error. Are the maintainers/developers looking into it? Even if its only documentation, something didn't get checked in.