Description of problem: I created kickstart profile with name, which is longer then 40 chars and then I added script to this profile by API. Postgresql generates tracebacks to logfile and satellite doesn't work correctly - sometimes I get internal server error on webui. This problem is only in satellite with postgresql (sat 5.6). Version-Release number of selected component (if applicable): spacewalk-java-2.0.2-15.el6sat.noarch How reproducible: only postgresql Steps to Reproduce: 1. create kickstart profile with name longer then 40 chars by API 2. add script to kickstart profile 2. python>> c.kickstart.createProfile(key, ... ) 3. python>> c.kickstart.profile.addScript(key, "kvm-qemu-auto-mon12aug2013_15_33_55_18375", 'script 1', 'sed s/BOOTPROTO=none/BOOTPROTO=dhcp/ /etc/sysconfig/network-scripts/ifcfg-eth0', '', 'post', 'true') Actual results: 500 Internal Server Error #traceback in catelina.out org.postgresql.util.PSQLException: ERROR: value too long for type character varying(40) at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2062) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1795) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:479) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:367) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:321) at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:79) at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:46) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2265) ... 65 more # pgsql log file: 2013-08-13 08:33:06.446 EDT ERROR: value too long for type character varying(40) 2013-08-13 08:33:06.446 EDT STATEMENT: insert into rhnKickstartScript (position, script_type, chroot, error_on_fail, raw_script, interpreter, script_name, data, kickstart_id, id) values ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10) 2013-08-13 08:33:06.456 EDT ERROR: current transaction is aborted, commands ignored until end of transaction block Expected results: Without traceback and satellite/postgresql works correctly.
EDIT: Reproducer is wrong. Problem is not length profile name, but name of script. 1. create kickstart profile 2. add script with name longer then 40 chars by API 2. python>> c.kickstart.createProfile(key, ... ) 3. python>> c.kickstart.profile.addScript(key, "kvm-qemu-auto-mon12aug2013_15_33_55_18375", 'script name must be longer then 40 characters', 'sed s/BOOTPROTO=none/BOOTPROTO=dhcp/ /etc/sysconfig/network-scripts/ifcfg-eth0', '', 'post', 'true')
Okay. Well first of all this is not a regression. Sat 5.5 did not experience this "problem" because Sat 5.5 did not allow you to name kickstart scripts added through the api. You now can, so it's now possible to submit a name that is longer than the max limit, whatever that max limit is. The webui carefully protects you from doing this, as it should, by ignoring further input after 40 characters. I also don't think this can be a postgres-specific problem. The field length is the same 40 characters regardless of the database type. All that being said, yes we should throw an error that is sensible to the user, not an ISE and an exception in the logs. I'm not sure that is nearly as high-priority as this bug is now marked, but it's an easy fix so I'll go ahead and do it now.
Committing to Spacewalk master: b3a914a301d321f732ff2efc0c6e939ee834bfe7
Hey Stephen, Pavel pointed me to the fix. The trouble of this BZ isn't really we cannot fit 42 chars into a 40 char long varchar2/character varying. The trouble is the fact postgresql do not recover from the exception and the Satellite stays unusable. This part is actually missing in the BZ. In API I believe there're thousands of places, where we do not check the input parameter length, so it's very easy to get into the situation. We most probably do not correctly rollback the failed transaction and postgresql refuses any other transactions (until postgresql is restarted). Pavel, would you paste some more logs to make the issue clear?
Hi, after I caused this problem (run API script with longer string), postgresql didn't work correctly and generated errors to logfile. Normal work isn't possible with satellite. Database must be restarted. It's easy way to break satellite. >> /var/lib/pgsql/data/pg_log/postgresql-Thu.log 2013-08-15 15:57:16.786 EDT ERROR: current transaction is aborted, commands ignored until end of transaction block 2013-08-15 15:57:16.786 EDT STATEMENT: insert into rhnKickstartScript (position, script_type, chroot, error_on_fail, raw_script, interpreter, script_name, data, kickstart_id, id) values ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10) 2013-08-15 15:57:16.786 EDT ERROR: current transaction is aborted, commands ignored until end of transaction block 2013-08-15 15:57:16.786 EDT STATEMENT: select 'c3p0 ping' from dual 2013-08-15 15:57:16.789 EDT ERROR: current transaction is aborted, commands ignored until end of transaction block 2013-08-15 15:57:16.789 EDT STATEMENT: insert into rhnKickstartScript (position, script_type, chroot, error_on_fail, raw_script, interpreter, script_name, data, kickstart_id, id) values ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10) 2013-08-15 15:57:16.789 EDT ERROR: current transaction is aborted, commands ignored until end of transaction block 2013-08-15 15:57:16.789 EDT STATEMENT: select 'c3p0 ping' from dual 2013-08-15 15:57:16.793 EDT ERROR: current transaction is aborted, commands ignored until end of transaction block 2013-08-15 15:57:16.793 EDT STATEMENT: select websession0_.id as id242_0_, websession0_.value as value242_0_, websession0_.web_user_id as web3_242_0_, websession0_.expires as expires242_0_ from PXTSessions websession0_ where websession0_.id=$1 2013-08-15 15:57:16.793 EDT ERROR: current transaction is aborted, commands ignored until end of transaction block 2013-08-15 15:57:16.793 EDT STATEMENT: select 'c3p0 ping' from dual
As there is no response to Comment#6 and Comment#7 I cloned the BZ to correctly address the issue -> Bug 998961.
Satellite 5.6 has been released. This bug was tracked under the release. This bug was either VERIFIED or RELEASE_PENDING (re-verified prior shortly before release). Moving to CLOSED CURRENT_RELEASE. Text from Upgrade Erratum follows: Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1395.html