(After setting up a few Spacewalk instances over the years, I've run into one of those... seemingly truly weird issues. Hopefully this is an easy one...)
I've got a spacewalk server named spacewalk1 (version 2.4) that had the postgresql DB on it. I recently moved the DB over to another host, and updated /etc/rhn/rhn.conf on the Spacewalk server to point to it. Things seemed to work, and then... a) I started seeing some newly-registered hosts try to do a 'rhn-profile-sync' and fail with the following: Updating package profile... Updating package profile D: rpcServer: Calling XMLRPC registration.welcome_message D: rpcServer: Calling XMLRPC registration.update_packages A protocol error occurred: Internal Server Error , attempt #1, An error has occurred: rhn-plugin: Error communicating with server. The message was: Internal Server Error See /var/log/up2date for more information Looking on the db server at postgresql-Fri.log (since today is Friday) I see the following: 2016-02-12 14:15:13.479 CST ERROR: current transaction is aborted, commands ignored until end of transaction block 2016-02-12 14:15:13.479 CST STATEMENT: SELECT queue_server(1000011758, 0) 2016-02-12 14:15:17.492 CST ERROR: password is required 2016-02-12 14:15:17.492 CST DETAIL: Non-superusers must provide a password in the connection string. 2016-02-12 14:15:17.492 CST CONTEXT: SQL statement "SELECT dblink_connect('at_conn', 'dbname=' || current_database() || ' port=' || coalesce(inet_server_port(), '5432'))" PL/pgSQL function "pg_dblink_exec" line 5 at PERFORM SQL statement "SELECT pg_dblink_exec( 'insert into rhnPackageEVR(id, epoch, version, release, evr) values (' || $1 || ', ' || $2 || ', ' || $3 || ', ' || $4 || ', evr_t(' || $2 || ', ' || $3 || ', ' || $4 || '))' )" PL/pgSQL function "lookup_evr" line 18 at PERFORM 2016-02-12 14:15:17.492 CST STATEMENT: insert into rhnServerPackage (server_id, name_id, evr_id, package_arch_id, installtime) values (1000011758, LOOKUP_PACKAGE_NAME(E'druid'), LOOKUP_EVR(NULL, E'0.8.3', E'0.1'), LOOKUP_PACKAGE_ARCH(E'noarch'), TO_TIMESTAMP(E'2016-02-11 15:12:08', 'YYYY-MM-DD HH24:MI:SS') ) 2016-02-12 14:15:17.495 CST ERROR: current transaction is aborted, commands ignored until end of transaction block 2016-02-12 14:15:17.495 CST STATEMENT: SELECT queue_server(1000011758, 0) b) I'm now seeing the following in the repo sync logs on the spacewalk server (/var/log/rhn/reposync/) [root@spacewalk1 reposync]# tail rhel7-x86_64-ulyaoth.log Repo URL: https://repos.ulyaoth.net/RHEL/7/x86_64/os/ Packages in repo: 436 Packages already synced: 435 Packages to sync: 1 1/1 : ulyaoth-nginx-mainline-1.9.11-1.el7-1.x86_64 (99999, 'ERROR: password is required', 'DETAIL: Non-superusers must provide a password in the connection string.\nCONTEXT: SQL statement "SELECT dblink_connect(\'at_conn\', \'dbname=\' || current_database() || \' port=\' || coalesce(inet_server_port(), \'5432\'))"\nPL/pgSQL function "pg_dblink_exec" line 5 at PERFORM\nSQL statement "SELECT pg_dblink_exec( \'insert into rhnPackageEVR(id, epoch, version, release, evr) values (\' || $1 || \', \' || $2 || \', \' || $3 || \', \' || $4 || \', evr_t(\' || $2 || \', \' || $3 || \', \' || $4 || \'))\' )"\nPL/pgSQL function "lookup_evr" line 18 at PERFORM\n', InternalError('password is required\nDETAIL: Non-superusers must provide a password in the connection string.\nCONTEXT: SQL statement "SELECT dblink_connect(\'at_conn\', \'dbname=\' || current_database() || \' port=\' || coalesce(inet_server_port(), \'5432\'))"\nPL/pgSQL function "pg_dblink_exec" line 5 at PERFORM\nSQL statement "SELECT pg_dblink_exec( \'insert into rhnPackageEVR(id, epoch, version, release, evr) values (\' || $1 || \', \' || $2 || \', \' || $3 || \', \' || $4 || \', evr_t(\' || $2 || \', \' || $3 || \', \' || $4 || \'))\' )"\nPL/pgSQL function "lookup_evr" line 18 at PERFORM\n',)) Linking packages to channel. Repo https://repos.ulyaoth.net/RHEL/7/x86_64/os/ has 0 errata. Sync completed. Total time: 0:01:38 [root@spacewalk1 reposync]# It seems like something didn't get updated to tell Spacewalk to use the remote dbusername and password, even though it's hitting the database server. Any ideas what I'm missing? Help! Thanks, -Ian
_______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list