[Spacewalk-devel] [PATCH] Script contents not properly displayed
Hello,
we found out that script contents are not properly displayed in the web UI
in Systems - Events - History (it's a perl page ...).
To reproduce:
- choose a system and go to Remote Command
- type in some script contents, e.g. a b c d e f g h
- schedule the command
- go to Events and click on the one just scheduled
- in the Details you will see (for the example above):
x23212f62696e2f73680a0a61206220632064206520662020672068
which is the ASCII code for
#!/bin/sh
a b c d e f g h
The attached patch fixes the problem by converting the ASCII codes into
a string using the pack() function.
Regards,
Johannes
--
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
From b00d36ff71783dd870e67cc969a9de2f55df4221 Mon Sep 17 00:00:00 2001
From: Johannes Renner jren...@suse.de
Date: Tue, 14 Aug 2012 11:46:43 +0200
Subject: [PATCH] Convert script contents from hex to string
---
web/modules/rhn/RHN/Server.pm |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/web/modules/rhn/RHN/Server.pm b/web/modules/rhn/RHN/Server.pm
index 3022a09..6c12939 100644
--- a/web/modules/rhn/RHN/Server.pm
+++ b/web/modules/rhn/RHN/Server.pm
@@ -491,8 +491,9 @@ sub render {
# sigh. there has to be an easier way to filter out ansi control codes...
$output-{OUTPUT} =~ s{\x1B\[(\d+[ABCDG]|[suK]|2J|(\d+;)*\d+m|=\d+[hl])}{}gism;
+ my $script = pack((H2)*, (substr($action-script_script, 1) =~ m/../g));
$ret-{server_event_details} .=
-sprintf(EOQ, $run_as, $action-script_timeout || 0, PXT::HTML-htmlify_text($action-script_script));
+sprintf(EOQ, $run_as, $action-script_timeout || 0, PXT::HTML-htmlify_text($script));
br/br/
Run as: strong%s/strongbr/
Timeout: strong%d/strong secondsbr/br/
--
1.7.7
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Script contents not properly displayed
Hi Johannes, Can you please give me more information on the system where you are experiencing this problem? We had a bug with identical symptoms where the root cause was that the defaults on how a particular object was stored (as ascii or as hex) in Postgresql changed in newer versions of the database. If that is the root cause of your problem, then it would not be safe to simply assume that we will always get hex back and expand it out to ascii, because that would generate errors for people who are running older versions of Postgresql. My cursory search has not turned up the original bug, but I will keep looking. -Stephen On 08/14/2012 06:18 AM, Johannes Renner wrote: Hello, we found out that script contents are not properly displayed in the web UI in Systems - Events - History (it's a perl page ...). To reproduce: - choose a system and go to Remote Command - type in some script contents, e.g. a b c d e f g h - schedule the command - go to Events and click on the one just scheduled - in the Details you will see (for the example above): x23212f62696e2f73680a0a61206220632064206520662020672068 which is the ASCII code for #!/bin/sh a b c d e f g h The attached patch fixes the problem by converting the ASCII codes into a string using the pack() function. Regards, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Script contents not properly displayed
On Tue, Aug 14, 2012 at 12:18:39PM +0200, Johannes Renner wrote: Hello, we found out that script contents are not properly displayed in the web UI in Systems - Events - History (it's a perl page ...). To reproduce: - choose a system and go to Remote Command - type in some script contents, e.g. a b c d e f g h - schedule the command - go to Events and click on the one just scheduled - in the Details you will see (for the example above): x23212f62696e2f73680a0a61206220632064206520662020672068 which is the ASCII code for #!/bin/sh a b c d e f g h The attached patch fixes the problem by converting the ASCII codes into a string using the pack() function. What Spacewalk version and what database is this exactly? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Script contents not properly displayed
Johannes, Could you ensure in /usr/share/pgsql/postgresql.conf that bytea_output = 'escape', and if not see if that corrects your problem? -Stephen On 08/14/2012 08:57 AM, Stephen Herr wrote: Hi Johannes, Can you please give me more information on the system where you are experiencing this problem? We had a bug with identical symptoms where the root cause was that the defaults on how a particular object was stored (as ascii or as hex) in Postgresql changed in newer versions of the database. If that is the root cause of your problem, then it would not be safe to simply assume that we will always get hex back and expand it out to ascii, because that would generate errors for people who are running older versions of Postgresql. My cursory search has not turned up the original bug, but I will keep looking. -Stephen On 08/14/2012 06:18 AM, Johannes Renner wrote: Hello, we found out that script contents are not properly displayed in the web UI in Systems - Events - History (it's a perl page ...). To reproduce: - choose a system and go to Remote Command - type in some script contents, e.g. a b c d e f g h - schedule the command - go to Events and click on the one just scheduled - in the Details you will see (for the example above): x23212f62696e2f73680a0a61206220632064206520662020672068 which is the ASCII code for #!/bin/sh a b c d e f g h The attached patch fixes the problem by converting the ASCII codes into a string using the pack() function. Regards, Johannes ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Script contents not properly displayed
On 08/14/2012 03:36 PM, Stephen Herr wrote: Johannes, Could you ensure in /usr/share/pgsql/postgresql.conf that bytea_output = 'escape', and if not see if that corrects your problem? -Stephen Thanks, setting this option fixes the problem on the postgres 9.1 database we are using. We also set standard_conforming_strings = 'off', do you think it makes still sense in combination with bytea_output = 'escape'? Thanks, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] option standard_conforming_strings in Pg breaks our code and data.
On Fri, Jun 15, 2012 at 08:28:04PM +0200, Miroslav Suchý wrote:
If you look at commit:
d8744d1693c1fc6e231278dd9a6537f269371192
and the code:
+if self.blob_map:
+for blob_var in self.blob_map.keys():
+ kw[blob_var] = kw[blob_var].replace('\\', '')
This worked fine in default Pg till version 9.0, but the behavior
depends on server side setting of option standard_conforming_strings
(boolean):
http://www.postgresql.org/docs/9.1/static/runtime-config-compatible.html
and this option changed its default value in 9.1. Which caused that
this statement corrupts data if \char appears in blob.
Why we could not use ordinary prepare here?
That would break existing 8.4-based installations, wouldn't it? Do we
have a way to hardcode setting the option upon connect so that we know
it behaves the way we assume even on older versions?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Script contents not properly displayed
On Tue, Aug 14, 2012 at 03:53:08PM +0200, Johannes Renner wrote: On 08/14/2012 03:36 PM, Stephen Herr wrote: Johannes, Could you ensure in /usr/share/pgsql/postgresql.conf that bytea_output = 'escape', and if not see if that corrects your problem? -Stephen Thanks, setting this option fixes the problem on the postgres 9.1 database we are using. We also set standard_conforming_strings = 'off', do you think it makes still sense in Mirek in https://www.redhat.com/archives/spacewalk-devel/2012-June/msg00023.html noted that the default changed with 9.1. We did not have time to investigate what this change could cause. combination with bytea_output = 'escape'? The bytea_output is about output, standard_conforming_strings is about literals on input. What I believe needs to be done is set these parameters on the per-connection basis (if possible) so that we don't depend on particular PostgreSQL server configuration (and defaults in different versions). -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
