[Spacewalk-devel] [PATCH] rhn-bootstrap: set specific profilename during registration process if it's given

2009-04-27 Thread Satoru SATOH
Hi,

This is an experimental patch to allow users to specify profilename for
client systems during registration process.

There is a case that client systems are registered as "unknown" name and
this patch can eliminate that, I think.


I've not tested it with the current spacewalk but it looks fine at least
in satellite-5.2.

Thanks,
Satoru SATOH


 spacewalk/certs-tools/rhn_bootstrap_strings.py |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/spacewalk/certs-tools/rhn_bootstrap_strings.py 
b/spacewalk/certs-tools/rhn_bootstrap_strings.py
index d1676fa..0f505a2 100644
--- a/spacewalk/certs-tools/rhn_bootstrap_strings.py
+++ b/spacewalk/certs-tools/rhn_bootstrap_strings.py
@@ -116,6 +116,14 @@ ALLOW_REMOTE_COMMANDS=%s
 
 FULLY_UPDATE_THIS_BOX=%s
 
+# Set if you want to specify profilename for client systems.
+# NOTE: Make sure it's set correctly if any external command is used.
+#
+# ex. PROFILENAME="foo.example.com"  # For specific clinet system
+# PROFILENAME=`hostname -s`  # Short hostname
+# PROFILENAME=`hostname -f`  # FQDN
+PROFILENAME=""   # Empty by default to let it be set automatically.
+
 #
 # -
 # DO NOT EDIT BEYOND THIS POINT ---
@@ -348,7 +356,12 @@ if [ $REGISTER_THIS_BOX -eq 1 ] ; then
 [ -f /etc/sysconfig/rhn/allowed-actions/configfiles/all ] || 
files="$files /etc/sysconfig/rhn/allowed-actions/configfiles/all"
 [ -n "$files" ] && touch  $files
 fi
-/usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS"
+if [ -z "$PROFILENAME" ] ; then
+profilename_opt=""
+else
+profilename_opt="--profilename=$PROFILENAME"
+fi
+/usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS" 
$profilename_opt
 [ -n "$files" ] && rm -f $files
 [ -n "$directories" ] && rmdir $(echo $directories | rev)
 echo
-- 
1.6.2.2

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] removing remote branches

2009-04-27 Thread Jesus Rodriguez
This is done now. We ended up with the following remote
branches:

  origin/HEAD
  origin/RELEASE-0.2
  origin/RELEASE-0.3
  origin/SPACEWALK-0.4
  origin/SPACEWALK-0.5
  origin/VADER
  origin/master
  origin/pgsql
  origin/playpen
  origin/schema-upgrade-0.2
  origin/spacewalk-repomd

jesus

-- 
jesus m. rodriguez| jes...@redhat.com
sr. software engineer | irc: zeus
rhn satellite & spacewalk | 919.754.4413 (w)
rhce # 805008586930012| 919.623.0080 (c)
+---+
|  "Those who cannot learn from history |
|   are doomed to repeat it."   |
|   -- George Santayana |
+---+

On Mon, Apr 27, 2009 at 08:59:56AM -0400, James Bowes wrote:
> On Mon, Apr 27, 2009 at 09:51:06AM +0200, Miroslav Suchý wrote:
> > Jesus M. Rodriguez wrote:
> >> Killed the following remote branches today:
> >>
> >> origin/thrift
> >> origin/iss
> >> origin/spacewalk-cobbler
> >> origin/origin/spacewalk-cobbler
> >> origin/multiorg
> >> origin/multiarch
> >>
> >>
> >> Here is what remains:
> >>
> >>   origin/errata-cache
> >>   origin/monitoring
> >>   origin/playpen
> >>   origin/postgresql
> >>   origin/schema-upgrade-0.2
> >>   origin/schemasandbox
> >>   origin/spacewalk-repomd
> >>
> >> Please let me know what these are for and if I can remove them.
> >
> > origin/monitoring can be deleted as well.
> >
> > BTW: how did you get it?
> > I have:
> > $ git branch -r
> >   origin/HEAD
> >   origin/RELEASE-0.2
> >   origin/RELEASE-0.3
> >   origin/SPACEWALK-0.4
> >   origin/SPACEWALK-0.5
> >   origin/VADER
> >   origin/errata-cache
> >   origin/master
> >   origin/multiarch
> >   origin/multiorg
> >   origin/pgsql
> >   origin/schemasandbox
> >   origin/spacewalk-cobbler
> >   origin/spacewalk-repomd
> >
> 
> Running 'git remote prune origin' will remove any tracking branches you
> have that no longer exist on the remote.
> 
> >
> >
> > -- 
> > Miroslav Suchy
> > Red Hat Satellite Engineering
> >
> > ___
> > Spacewalk-devel mailing list
> > Spacewalk-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-devel
> 
> -James



> ___
> 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


[Spacewalk-devel] Re: Missing tag for spacewalk-utils

2009-04-27 Thread Brad Buckingham

Miroslav Suchý wrote:

Ops,
Package spacewalk-utils is in releng/packages/spacewalk-utils in 
version 0.6.1-1, but there is no such tag there.
I blame: 4853fe71 (Brad Buckingham 2009-04-07 16:29:15 -0400 1) 
0.6.1-1 utils/


Sincerely
the watchdog

Package should now be tagged in master.

ref: 
http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=4b882fb3a94726cb63db04c973147386f0ecd0de


Thanks "watchdog" :)

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Tom Lane
=?ISO-8859-2?Q?Miroslav_Such=FD?=  writes:
> Tom Lane wrote:
>> Isn't this a complete waste of time?  There is exactly 0 chance of
>> migrating all those procedures to mysql.

> How do you know?

Try it for awhile and see what you think.  The incompatibilities and
missing features you're running into in the DDL are just the tip of
the iceberg.

regards, tom lane

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Miroslav Suchý

Tom Lane wrote:

Matej Hasul  writes:

Hello, I started working on migrating tables to mysql.


Isn't this a complete waste of time?  There is exactly 0 chance of
migrating all those procedures to mysql.



How do you know?


--
Miroslav Suchy
Red Hat Satellite Engineering

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Tom Lane
Matej Hasul  writes:
> Hello, I started working on migrating tables to mysql.

Isn't this a complete waste of time?  There is exactly 0 chance of
migrating all those procedures to mysql.

regards, tom lane

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Miroslav Suchý

Matej Hasul wrote:

Hello, I started working on migrating tables to mysql.

Data types conversion looks like this:

varchar2 -> varchar
number -> numeric
date -> timestamp


For the records. Matej is trying to rewrite queries in run time to be 
MySQL compatible...




Following problems emerged:
1. Mysql doesn`t support user defined data type. So I have no idea what 
to do with evr_t.


map it to different table? I.e change evr_t to integer and use it as 
look up value to table EVR with columns epoch, version, release and 
queries which use it expand to join with this table?


2. Mysql doesn`t support nested tables. For example something like 
"create or replace type channel_name_t as table of varchar(64)". Does 
anyone know some workaround?


The same, leave it as normal table and join it with original in runtime.

3. Check constraint not working. According to mysql documentation - "The 
CHECK clause is parsed but ignored by all storage engines".
Workaround: Use before-insert-or-update trigger to implement check 
constraint.


If possible. But I think we can live without these constraints. Whover 
will use mysql can not have the same data consistency as in Oracle or 
PostgreSQL by definition.


4. Create table test(date1 date default (sysdate), date2 date default 
(sysdate)) will not work in mysql, because there can be only one date 
column with default clause.

Workaround: Use before-insert-or-update trigger to set actual date(s).


Err. There can be more default columt with date. But the value have to 
be constant, not the function.

Yeah, trigger can fix it.


5. Missing sequence in mysql.
Workaround: One option is to use AUTO_INCREMENT and LAST_INSERT_ID(). 
Another option is to create table holding sequence number and create 
procedures curval('seq_name') and nextval('seq_name').


I think AUTO_INCREMENT and LAST_INSERT_ID() meets our needs.
But yeah, creating table which hold the sequence better map to sequence 
as we all know it. But remember that it can not be table which support 
transaction, otherwise you will be recycling the numbers from sequence.


--
Miroslav Suchy
Red Hat Satellite Engineering

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


[Spacewalk-devel] MySQL porting info

2009-04-27 Thread Matej Hasul
Hello, I started working on migrating tables to mysql.

Data types conversion looks like this:

varchar2 -> varchar
number -> numeric
date -> timestamp

Following problems emerged:
1. Mysql doesn`t support user defined data type. So I have no idea what to
do with evr_t.

2. Mysql doesn`t support nested tables. For example something like "create
or replace type channel_name_t as table of varchar(64)". Does anyone know
some workaround?

3. Check constraint not working. According to mysql documentation - "The
CHECK clause is parsed but ignored by all storage engines".
Workaround: Use before-insert-or-update trigger to implement check
constraint.

4. Create table test(date1 date default (sysdate), date2 date default
(sysdate)) will not work in mysql, because there can be only one date column
with default clause.
Workaround: Use before-insert-or-update trigger to set actual date(s).

5. Missing sequence in mysql.
Workaround: One option is to use AUTO_INCREMENT and LAST_INSERT_ID().
Another option is to create table holding sequence number and create
procedures curval('seq_name') and nextval('seq_name').

Comments are welcome.
Matej Hasul
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Re: [Spacewalk-devel] removing remote branches

2009-04-27 Thread James Bowes
On Mon, Apr 27, 2009 at 09:51:06AM +0200, Miroslav Suchý wrote:
> Jesus M. Rodriguez wrote:
>> Killed the following remote branches today:
>>
>> origin/thrift
>> origin/iss
>> origin/spacewalk-cobbler
>> origin/origin/spacewalk-cobbler
>> origin/multiorg
>> origin/multiarch
>>
>>
>> Here is what remains:
>>
>>   origin/errata-cache
>>   origin/monitoring
>>   origin/playpen
>>   origin/postgresql
>>   origin/schema-upgrade-0.2
>>   origin/schemasandbox
>>   origin/spacewalk-repomd
>>
>> Please let me know what these are for and if I can remove them.
>
> origin/monitoring can be deleted as well.
>
> BTW: how did you get it?
> I have:
> $ git branch -r
>   origin/HEAD
>   origin/RELEASE-0.2
>   origin/RELEASE-0.3
>   origin/SPACEWALK-0.4
>   origin/SPACEWALK-0.5
>   origin/VADER
>   origin/errata-cache
>   origin/master
>   origin/multiarch
>   origin/multiorg
>   origin/pgsql
>   origin/schemasandbox
>   origin/spacewalk-cobbler
>   origin/spacewalk-repomd
>

Running 'git remote prune origin' will remove any tracking branches you
have that no longer exist on the remote.

>
>
> -- 
> Miroslav Suchy
> Red Hat Satellite Engineering
>
> ___
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel

-James


pgpbUYdkSgCSA.pgp
Description: PGP signature
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] Missing tag for spacewalk-utils

2009-04-27 Thread Miroslav Suchý

Ops,
Package spacewalk-utils is in releng/packages/spacewalk-utils in version 
0.6.1-1, but there is no such tag there.
I blame: 4853fe71 (Brad Buckingham 2009-04-07 16:29:15 -0400 1) 0.6.1-1 
utils/


Sincerely
the watchdog

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] Proposed commit hook to catch suspicious merge commits

2009-04-27 Thread Jan Pazdziora
On Thu, Apr 16, 2009 at 09:51:33AM +0200, Jan Pazdziora wrote:
> 
> Since there were no objections, I assume people have tested the code
> and are OK with it. I'm about to drop an email to
> fedora-infrastructure -- please shout now if you do not want to see
> that commit hook on Spacewalk upstream repository.

For your information -- the hook was activated on Spacewalk git
repository at ssh://git.fedorahosted.org/git/spacewalk.git/ now.

If you try to push a commit which is a merge and has a commit
message which looks like an automatic merge, you will get an error
like this:

$ git push
Counting objects: 12, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 763 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
Commit [22709bf42f9effdc4dcc3acc31eb95c2952e3386] looks like automatic merge 
when you did not rebase after pull.
To ssh://git.fedorahosted.org/git/spacewalk.git/
 ! [remote rejected] master -> master (pre-receive hook declined)
error: hooks/pre-receive exited with error code 1
error: failed to push some refs to 
'ssh://git.fedorahosted.org/git/spacewalk.git/'

In other words: if you see this error, it's because you are try to
to push merge without rebase.

The fix is to rebase:

$ git rebase origin/master
First, rewinding head to replay your work on top of it...
Applying: spacewalk-selinux: amend %changelog.

... review the result with

$ gitk --all &

... and if you are happy with the result, push:

$ git push
Counting objects: 9, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 481 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/spacewalk.git/
   15122b3..81ee3ac  master -> master
$

-- 
Jan Pazdziora
Senior 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] removing remote branches

2009-04-27 Thread Miroslav Suchý

Jesus M. Rodriguez wrote:

Killed the following remote branches today:

origin/thrift
origin/iss
origin/spacewalk-cobbler
origin/origin/spacewalk-cobbler
origin/multiorg
origin/multiarch


Here is what remains:

  origin/errata-cache
  origin/monitoring
  origin/playpen
  origin/postgresql
  origin/schema-upgrade-0.2
  origin/schemasandbox
  origin/spacewalk-repomd

Please let me know what these are for and if I can remove them.


origin/monitoring can be deleted as well.

BTW: how did you get it?
I have:
$ git branch -r
  origin/HEAD
  origin/RELEASE-0.2
  origin/RELEASE-0.3
  origin/SPACEWALK-0.4
  origin/SPACEWALK-0.5
  origin/VADER
  origin/errata-cache
  origin/master
  origin/multiarch
  origin/multiorg
  origin/pgsql
  origin/schemasandbox
  origin/spacewalk-cobbler
  origin/spacewalk-repomd



--
Miroslav Suchy
Red Hat Satellite Engineering

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel