[Spacewalk-devel] PGPORT: additional packages
Hi Devan, Attached are additional packages that need to be checked into the repository. Since I do not have rights to check them in, could you please check them into the following location: spacewalk/schema/spacewalk/postgresql/packages/ Thanks Vikram Rai EnterpriseDB rhn_packages.tar.gz Description: GNU Zip compressed data ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT
Hi, The first set of files for query tagging have been pushed to the git repository. spacewalk/backend/server/test/unit-test/test_rhnServerGroup.py spacewalk/backend/server/test/test_leak3.py spacewalk/backend/server/test/test_leak2.py spacewalk/backend/server/test/test_leak.py spacewalk/backend/server/test/test_dcoracle2.py spacewalk/backend/server/test/test-cx_Oracle-memleak.py spacewalk/backend/server/test/TestServer.py spacewalk/backend/server/rhnUser.py spacewalk/backend/server/rhnServer/server_token.py spacewalk/backend/server/rhnServer/server_kickstart.py spacewalk/backend/server/rhnSQL/sql_base.py spacewalk/backend/server/rhnSQL/driver_cx_Oracle.py Regards, Vikram Rai EnterpriseDB ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PGPORT (regarding queries)
Hi, I have updated wiki with the process to tag the queries. The below link would be used to track changes: https://fedorahosted.org/spacewalk/wiki/PgportQueries And the following link has examples for query tagging: https://fedorahosted.org/spacewalk/wiki/QueryTaggingExamples Regards, Vikram Rai EnterpriseDB On Thu, Feb 26, 2009 at 4:12 AM, Bruce Momjian wrote: > > Here is where the query type numbers are defined: > >https://fedorahosted.org/spacewalk/wiki/PostgresTechnicalApproach > > > ----------- > > Vikram Rai wrote: > > Hi, > > > > We have started looking at the queries that need to be tagged. > > In the initial stages of going through these queries we found a > couple > > of things and some ways we can tag them. > > > > Keeping in mind the diversity and complexity of the some of the > queries > > we have divided them into four categories: > > > >1. Queries that need to have minor changes to make them work in > postgres. > > > > For eg: It could be like adding an "as" clause for alias names etc. > > We had a suggestion to tag them with the following comment where ever > > the changes are necessary: > > > > pgsql_c:xxx --> which is postgresql_comment:line number. > > > > 2. Queries that need to be rewritten. We had gone through a couple of > > them as we went along the list and found some queries that had to be > > rewritten to give an exact result. For eg: queries on system catalogs in > > oracle do not work in postgres. > > > > we would be tagging such queries with the following comment: > > > > pgsql_q:xxx --> which is postgresql_query:line number. > > > > 3. Incase there are any db changes to accommodate a query using > Orafce, > > such queries would be tagged as: > > > > pgsql_orafce:xxx --> which is postgresql_database_change:line number. > > > > 4. No changes required to the existing query. Works both on postgres > and > > oracle. > > > > pgsql_ora:xxx --> which is works on both postgres and oracle:line > > number. > > > > These are just some initial thoughts and I am sure we will have some > > additions to it down the road as we unfold some more of them. Do let me > > know what you think. > > > > Regards, > > > > Vikram Rai > > EnterpriseDB > > > ___ > > Spacewalk-devel mailing list > > Spacewalk-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/spacewalk-devel > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ___ > 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] PGPORT (regarding queries)
Please see comments inline and marked as Vik>> On Tue, Feb 24, 2009 at 9:00 PM, Jeff Ortel wrote: > Thanks for sending this out. > > A couple of questions: > > * Why did we abandon the tagging using number (1-5) and decide to go with > letters/words. > This seems more prone to error. Vik >> We can definitely go with numbers. if we agree that they will be less prone to errors. > > * Is the line # relative to the query? Like PGPORT_xx:3 for line #3 in the > query? > or is it the absolute line # in the file. If the later, I would suggest > we don't do > this because: 1) grep will give us the file/line#. 2) if lines are > inserted during the > tagging process or (merging w/ master), the line # will be wrong. > Vik>> They are relative to the query > > See below: > > Vikram Rai wrote: > >> Hi, >> >>We have started looking at the queries that need to be tagged. >>In the initial stages of going through these queries we found a couple >> of things and some ways we can tag them. >> >>Keeping in mind the diversity and complexity of the some of the queries >> we have divided them into four categories: >> >> 1. Queries that need to have minor changes to make them work in >> postgres. >> >>For eg: It could be like adding an "as" clause for alias names etc. >>We had a suggestion to tag them with the following comment where ever >> the changes are necessary: >> >>pgsql_c:xxx --> which is postgresql_comment:line number. >> > > Why "c"? - seems arbitrary or at least I don't get it :)Vik>> PGPORT(as > clause)? If we add this to every line in a query it will make it a lot > complicated. We can use a general clause for the whole query. We can put > PGPORT(as clause):xxx PGPORT(order by):xxx. Do let me know your thoughts. > > >>2. Queries that need to be rewritten. We had gone through a couple of >> them as we went along the list and found some queries that had to be >> rewritten to give an exact result. For eg: queries on system catalogs in >> oracle do not work in postgres. >> >>we would be tagging such queries with the following comment: >> >>pgsql_q:xxx --> which is postgresql_query:line number. >> > > Why "q"? - seems arbitrary or at least I don't get it :). Vik>> more or less the same thing i was trying to explain in #1 > > > >>3. Incase there are any db changes to accommodate a query using Orafce, >> such queries would be tagged as: >> >>pgsql_orafce:xxx --> which is postgresql_database_change:line number. >> > > I'd like to have a convention where we're more specific. In addition to > tagging as a #3, and that we *might* leverage orafce, I'd like to tag it > with what feature(s) in orafce such as NVL, DECODE(), .. > Vik>> ok that can be done. > > Also, a query might be tagged as a #3 and not leverage orafce but require > another compatability measure such as a DB function or procedure. I'd like > to account for this. > Vik >> will add it. > >> >>4. No changes required to the existing query. Works both on postgres >> and oracle. >> >>pgsql_ora:xxx --> which is works on both postgres and oracle:line >> number. >> > > Why "ora"? - seems arbitrary or at least I don't get it :) > Vik >> any suggestions here? If a query works for both what other tagging > options can we use? > >> >>These are just some initial thoughts and I am sure we will have some >> additions to it down the road as we unfold some more of them. Do let me >> know what you think. >> >>Regards, >> >>Vikram Rai >>EnterpriseDB >> >> >> >> >> ___ >> 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 mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PGPORT (regarding queries)
Hi,
We have started looking at the queries that need to be tagged.
In the initial stages of going through these queries we found a couple
of things and some ways we can tag them.
Keeping in mind the diversity and complexity of the some of the queries
we have divided them into four categories:
1. Queries that need to have minor changes to make them work in postgres.
For eg: It could be like adding an "as" clause for alias names etc.
We had a suggestion to tag them with the following comment where ever
the changes are necessary:
pgsql_c:xxx --> which is postgresql_comment:line number.
2. Queries that need to be rewritten. We had gone through a couple of
them as we went along the list and found some queries that had to be
rewritten to give an exact result. For eg: queries on system catalogs in
oracle do not work in postgres.
we would be tagging such queries with the following comment:
pgsql_q:xxx --> which is postgresql_query:line number.
3. Incase there are any db changes to accommodate a query using Orafce,
such queries would be tagged as:
pgsql_orafce:xxx --> which is postgresql_database_change:line number.
4. No changes required to the existing query. Works both on postgres and
oracle.
pgsql_ora:xxx --> which is works on both postgres and oracle:line
number.
These are just some initial thoughts and I am sure we will have some
additions to it down the road as we unfold some more of them. Do let me
know what you think.
Regards,
Vikram Rai
EnterpriseDB
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: PGPORT: Porting tables; contributions needed
Hi, Just did a fresh pull and seems like the following are already in the postgres folder. So am leaving them for now: rhnServerAction.sql rhnServerArch_data.sql rhnServerArch.sql rhnServerGroup.sql rhnServerGroupType.sql rhnServer.sql Regards, Vikram Rai On Fri, Feb 6, 2009 at 2:38 PM, Vikram Rai wrote: > I have started working on the following tables: > > rhnServerActionPackageResult.sql > rhnServerActionScriptResult.sql > rhnServerAction.sql > rhnServerActionVerifyMissing.sql > rhnServerActionVerifyResult.sql > rhnServerArch.sql > rhnServerCacheInfo.sql > rhnServerChannelArchCompat_data.sql > rhnServerChannelArchCompat.sql > rhnServerChannel.sql > rhnServerConfigChannel.sql > rhnServerCustomDataValue.sql > rhnServerDMI.sql > rhnServerEvent.sql > rhnServerGroup_indexes.sql > rhnServerGroupMembers_email_triggers.sql > rhnServerGroupMembers_indexes.sql > rhnServerGroupMembers.sql > rhnServerGroupNotes.sql > rhnServerGroup.sql > rhnServerGroupTypeFeature.sql > rhnServerGroupType.sql > rhnServerHistory.sql > rhnServerInfo.sql > rhnServerInstallInfo.sql > rhnServerLocation.sql > rhnServerLock.sql > rhnServerMessage.sql > > Regards, > > Vikram Rai > > EnterpriseDB > On Wed, Feb 4, 2009 at 9:21 PM, Vikram Rai wrote: > >> Hi, >> >> Just an FYI >> I have started working on the following tables: >> >> RHNVERSIONINFO : reference tables: >> RHNPACKAGEEVR >> RHNPACKAGENAME >> >> RHNVIRTSUBLEVEL >> RHNVIRTUALINSTANCE >> RHNVIRTUALINSTANCEEVENTLOG >> RHNVIRTUALINSTANCEEVENTTYPE >> RHNVIRTUALINSTANCEINFO >> RHNVIRTUALINSTANCEINSTALLLOG >> RHNVIRTUALINSTANCESTATE >> RHNVIRTUALINSTANCETYPE >> RHNVISIBLEOBJECTS >> >> Regards, >> >> Vikram Rai >> > > ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: PGPORT: Porting tables; contributions needed
I have started working on the following tables: rhnServerActionPackageResult.sql rhnServerActionScriptResult.sql rhnServerAction.sql rhnServerActionVerifyMissing.sql rhnServerActionVerifyResult.sql rhnServerArch.sql rhnServerCacheInfo.sql rhnServerChannelArchCompat_data.sql rhnServerChannelArchCompat.sql rhnServerChannel.sql rhnServerConfigChannel.sql rhnServerCustomDataValue.sql rhnServerDMI.sql rhnServerEvent.sql rhnServerGroup_indexes.sql rhnServerGroupMembers_email_triggers.sql rhnServerGroupMembers_indexes.sql rhnServerGroupMembers.sql rhnServerGroupNotes.sql rhnServerGroup.sql rhnServerGroupTypeFeature.sql rhnServerGroupType.sql rhnServerHistory.sql rhnServerInfo.sql rhnServerInstallInfo.sql rhnServerLocation.sql rhnServerLock.sql rhnServerMessage.sql Regards, Vikram Rai EnterpriseDB On Wed, Feb 4, 2009 at 9:21 PM, Vikram Rai wrote: > Hi, > > Just an FYI > I have started working on the following tables: > > RHNVERSIONINFO : reference tables: > RHNPACKAGEEVR > RHNPACKAGENAME > > RHNVIRTSUBLEVEL > RHNVIRTUALINSTANCE > RHNVIRTUALINSTANCEEVENTLOG > RHNVIRTUALINSTANCEEVENTTYPE > RHNVIRTUALINSTANCEINFO > RHNVIRTUALINSTANCEINSTALLLOG > RHNVIRTUALINSTANCESTATE > RHNVIRTUALINSTANCETYPE > RHNVISIBLEOBJECTS > > Regards, > > Vikram Rai > ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: PGPORT: Porting tables; contributions needed
Hi, Just an FYI I have started working on the following tables: RHNVERSIONINFO : reference tables: RHNPACKAGEEVR RHNPACKAGENAME RHNVIRTSUBLEVEL RHNVIRTUALINSTANCE RHNVIRTUALINSTANCEEVENTLOG RHNVIRTUALINSTANCEEVENTTYPE RHNVIRTUALINSTANCEINFO RHNVIRTUALINSTANCEINSTALLLOG RHNVIRTUALINSTANCESTATE RHNVIRTUALINSTANCETYPE RHNVISIBLEOBJECTS Regards, Vikram Rai On Wed, Feb 4, 2009 at 4:22 PM, Muhammad Farrukh < muhammad.farr...@enterprisedb.com> wrote: > I am going to start with the below tables: > > rhnAllowTrust.sql > rhnAppInstallInstance.sql > rhnAppInstallSessionData.sql > rhnAppInstallSession.sql > rhnArchTypeActions_data.sql > rhnArchTypeActions.sql > rhnArchType_data.sql > rhnArchType.sql > rhnActionVirtSuspend.sql > > Best Regards, > Farrukh > > On Tue, Feb 3, 2009 at 4:18 PM, Gurjeet Singh < > gurjeet.si...@enterprisedb.com> wrote: > >> I am starting to work on the following set of tables: >> >> schema/spacewalk/rhnsat/tables/rhnAction*.sql >> >> Best regards, >> >> On Tue, Feb 3, 2009 at 12:47 PM, Gurjeet Singh < >> gurjeet.si...@enterprisedb.com> wrote: >> >>> Hi All, >>> >>> I have migrated the following DB objects to work okay with Postgres: >>> >>> ./procs/create_first_org.sql >>> ./tables/web_customer.sql >>> ./tables/rhnUserGroupType.sql >>> ./tables/rhnUserGroup.sql >>> ./tables/rhnOrgQuota.sql >>> ./tables/rhnUserGroup_sequences.sql >>> ./tables/rhnServerGroupType.sql >>> ./tables/rhnUserGroupType_data.sql >>> ./tables/rhnServerGroup.sql >>> ./triggers/rhnOrgQuota.sql >>> >>> And follwing are the two new files: >>> >>> ./main.sql >>> ./tables/dual.sql >>> >>> Here I will list out the instructions and lessons learnt so that any >>> of you who wishes to contribute to this effort can start submitting patches. >>> Look at the above objects for refernce, anddo not hesitate to ask questions, >>> here or on IRC. >>> >>> Create a local branch off of pgsql branch, this is where all the fun is. >>> Copy the files you want to work on from >>> schema/spacewalk/rhnsat//fileame.sql to >>> schema/spacewalk/postgresql//fileame.sql and then start working >>> on it. >>> >>> We need to migrate objects in the following order of prefernce: >>> Tables, Triggers, Sequences, Views, Procedures. >>> >>> We are leaving out the Objects, Packages, and Synonyms for now for >>> various reasons. If you feel comfortable doing these, you are welcome >>> (synonyms are not portable, so don;t bother with those). >>> >>> === Compacting DDL === >>> >>> While migrating these objects, we wish to compact the DDL to the point >>> where it looks sane and does not look like a bloat. For example, >>> >>> 1) Remove the constraint name from NOT NULL constraints. But keep the >>> Foreign Key, Primary Key and CHECK constraint names. >>> >>> 2) Try to club together the various declarations for the same column. For >>> example, there a re a few table DDLs where a column is declared NOT NULL and >>> (either in CREATE statememt, or using ALTER TABLE), a Primary Key is also >>> specified on the same. In such a case, get rid of the NOT NULL, and put the >>> PRIMARY KEY clause right next to the column. >>> >>> 3) If there's a multi-column primary key, specify that in the CREATE >>> TABLE command itself, instead of ALTER TABLE ADD CONSTRAINT... >>> >>> 4) If you see a VARCHAR(1) or a CHAR(1) column datatype, and if you think >>> the application might be using it as a boolean (Y/N), then just put a TODO >>> item on top of that column saying "TODO: Should this be a boolean?". >>> >>> 5) Convert all NUMBER datatypes to NUMERIC. Soon we will be identifying >>> the columns whose precision can be reduced to use just INT/BIGINT, because >>> Postgres' NUMERIC datatype does not perform all that well. >>> >>> 6) Convert all DATE datatype columns to TIMESTAMP. >>> >>> 7) Replace SYSDATE usage (in DEFAULTs etc. ) with CURRENT_TIMESTAMP. >>> >>> 8) Remember to keep the TABLESPACE clauses when you move a UNIQUE >>> INDEX/PRIMARY KEY from outside to inside the CREATE TABLE. >>> >>> 9) Sometimes there are TRIGGERS created in the same file as the table's. >>> We need to strip out those and create a file by the same name in triggers/ >>> directory an
Re: [Spacewalk-devel] Changes needed in wiki for CentOS development environment setup
Hi,
We have put together a document for deploying the Spacewalk dev environment
on CentOS 5.
There were a couple of steps that we had to do in order to make it working
on our local machines.
Please go through the attached document and let us know if the document
seems ok.
We had a suggestion to put this document as a separate link on the wiki for
install instructions for CentOS.
Regards,
Vikram Rai
EnterpriseDB
On Wed, Jan 28, 2009 at 4:12 AM, Gurjeet Singh <
gurjeet.si...@enterprisedb.com> wrote:
> Hi All,
>
> I followed the guide at
> https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup and
> tried to setup a dev env on CentOS 5.2.
>
> Here's what I started with:
> Clean install of CentOS, with a few packeges that make sense for
> Spacewalk like webserver, etc.
> Disable SELinux policy in /etc/selinux/config (SELINUX=disabled)
>
> And then while following the instructions, I had to perform the
> following 4 additional steps to get the env up and running:
>
> 1) During Spacewalk installation, before the following step:
>
> rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former
>
> Do this as root:
>
> wget -O /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-former
> http://www.redhat.com/security/db42a60e.txt
>
> 2) Instead of
>
> ../rel-eng/bin/build.py --test --rpm &&
> /tmp/spacewalk-build/noarch/spacewalk-search-*.git.*.noarch.rpm
>
> do this:
>
> ../rel-eng/bin/build.py --test --rpm && sudo rpm -Uvh
> /tmp/spacewalk-build/noarch/spacewalk-search-*.git.*.noarch.rpm
>
> 3) After 'Web Application Installation' section, I had to replace two
> symlinks with their targets, and then restart the spacewalk service.
> (as root)
> cd /var/www
> ls -l html
> html -> /home/dev/spacewalk/web/html
> mv html html.orig; cp -r -L /home/dev/spacewalk/web/html html
>
> cd /usr/share/tomcat5/webapps/
> ls -l rhn
> rhn -> /home/dev/spacewalk/java/rhnwebapp
> mv rhn rhn.orig; cp -r -L /home/dev/spacewalk/java/rhnwebapp rhn
>
> /usr/sbin/rhn-satellite restart
>
> 4) Under section 'Deploying development schema' the usage of
> /etc/init.d/rhn-satellite should be changed to /usr/sbin/rhn-satellite.
>
> 5) The GITDIR environment variable is used in three places, but is never
> asked to be initialized anywhere. In my case, when doing 'Web Application
> Installation' section, GITDIR was supposed to be /home/dev/ and when in
> section 'Deploying development schema' it is supposed to point to
> /home/dev/spacewalk (otherwise cd $GITDIR/schema/spacewalk wouldn't work).
>
> So, IMHO, it should point to /home/dev/spacewalk so that ls $GITDIR
> shows schema/ contrib/ playpen/ etc.
>
> Also, since this variable can be easily confused with Git's own GIT_DIR
> (which is seldom used, but points to .git/ in a repo), lets change this
> variable to SRCDIR or something similar.
>
> Best regards,
> --
> gurjeet[.sin...@enterprisedb.com
> EnterpriseDB http://www.enterprisedb.com
>
> singh.gurj...@{ gmail | hotmail | indiatimes | yahoo }.com
>
>
> ___
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel
>
Spacewalk install guide (CentOS)
Description: Binary data
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] schema update issue
we ran into the same issue and and figured out that spacewalk should be
installed before you run this command.
refer the giude below and let me know if it gets u all the way through.
https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup
regards,
vikram
On Sun, Jan 18, 2009 at 8:19 AM, Travis Camechis wrote:
> I am trying to deploy the development schema as documented under the wiki
>
> I am running this command
>
> make satellite-clean satellite-release TBS=USERS
> SQLUSER=spacewalk/spacew...@xe
>
> It goes for awhile setting up the DB and then dies with this error. Does
> anyone have any suggestions ?
>
> SQL_FILE
> -
>
> rhnsat/tables/rhnVersionInfo_data.sql
>
>
> S
> -
>
>
>
> 0 rows deleted.
>
>
> 1 row created.
>
>
> Commit complete.
>
>
> SQL_FILE
> ---
> rhnsat/quit.sql
>
> Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 -
> Production
>
> SQL*Plus: Release 10.2.0.4.0 - Production on Sat Jan 17 21:46:28 2009
>
> Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
>
> ERROR:
> ORA-12154: TNS:could not resolve the connect identifier specified
>
>
> Enter user-name:
> SQL*Plus: Release 10.2.0.4.0 - Production on Sat Jan 17 21:46:29 2009
>
> Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
>
> ERROR:
> ORA-12154: TNS:could not resolve the connect identifier specified
>
>
> Enter user-name: SP2-0306: Invalid option.
> Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
> where ::= [/][@] | /
> SP2-0306: Invalid option.
>
> Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
> where ::= [/][@] | /
> SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
>
> make[1]: *** [universe.satellite-synonyms.lst] Error 255
> make[1]: Leaving directory `/mnt/projects/spacewalk/schema/spacewalk'
> make: *** [test-make-release] Error 2
>
>
>
> ___
> 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] PGPORT (installation issue using make)
Hi Jeff,
Here is what we have tried so far:
Installed spacewalk with version 0.3 and got permission denied and internal
errors which do not give information as to what went wrong.
Installed 0.4 and got:
Tomcat failed to start properly or the installer ran out of tries. Please
check /var/log/tomcat5/catalina.out for errors. Which does not give proper
information as to what is missing.
We have tried the guide and all information available on the net to install
a dev environment with source and have reached so far as to say that the
documents do not have information to say that on a fresh redhat5 enterprise
server you would need the following pre- requisites.
My question here is that, what guide would be best to follow to know how to
get around these errors that we are facing? Is there a list of
pre-requisites or deps available? It might make things easier.
If it works on one system and not on the other then there is something
missing and I would like to narrow this down to what is it that is required
for an install??
Thanks in advance.
Regards,
Vikram Rai
On Thu, Jan 15, 2009 at 7:57 PM, tushar ahuja wrote:
> Hi Jeff,
>
> Thanks for the link .We have started the installation for creating a devel
> environment on Red-Hat5.
>
> These are the Steps which we have used :-
>
> 1)We have installed spacewalk using rmp (yum install spacewalk)
> 2)at the time of configuration (spacewalk-setup --disconnected), we found
> tomcat failed to start just before the installation ,but somehow we found
> the solution and fix it.
> 3)we opened GUI interface (https://localhost.localdomain) and created a
> administrator user and password wow :-)
> 4) we installed/configured git(using rpm) and also clone the spacewalk
> repository successfully
> 5)Now at the time of installation "WEB APPLICATION" ,we performed all the
> Steps mentioned in the wiki successfully.
>
> But whenever i am trying to open browser for spacewalk server(
> https://localhost.localdomain)
> i am getting this error message
>
> Forbidden
>
> You don't have permission to access / on this server.
>
> Additionally, a 403 Forbidden error was encountered while trying to use an
> ErrorDocument to handle the request.
> --
> Apache/2.2.3 (Red Hat) Server at 127.0.0.1 Port 80
>
> it look like a Apache issue but i am not able to solve it.
>
> Any idea how to solve this ?
>
> thanks in advance,
>---
> regards,tushar
>
>
> On Thu, Jan 15, 2009 at 12:27 AM, Jeff Ortel wrote:
>
>> Hey Vikram,
>>
>> I'd suggest you follow the developer setup instructions on the Spacewalk
>> wiki:
>>
>> https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup
>>
>> ~jeff
>>
>>
>> Vikram Rai wrote:
>>
>>> Hi,
>>>
>>> We were trying to install spacewalk using souce on Redhat 5 Enterprise
>>> Server and after giving the command:
>>>
>>> make spacewalk-clean spacewalk-release TBS=USERS
>>> SQLUSER=spacewalk/spacew...@xe
>>>
>>> We are getting the below error after the schema is created:
>>> Attached is the log file of make command
>>>
>>> 1 row created.
>>>
>>>
>>> Commit complete.
>>>
>>>
>>> SQL_FILE
>>> ---
>>> rhnsat/quit.sql
>>>
>>> Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0
>>> - Production
>>>
>>> SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jan 14 19:50:24 2009
>>>
>>> Copyright (c) 1982, 2005, Oracle. All rights reserved.
>>>
>>> ERROR:
>>> ORA-12154: TNS:could not resolve the connect identifier specified
>>>
>>>
>>> Enter user-name:
>>> SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jan 14 19:50:24 2009
>>>
>>> Copyright (c) 1982, 2005, Oracle. All rights reserved.
>>>
>>> ERROR:
>>> ORA-12154: TNS:could not resolve the connect identifier specified
>>>
>>>
>>> Enter user-name: SP2-0306: Invalid option.
>>> Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
>>> where ::= [/][@] | /
>>> SP2-0306: Invalid option.
>>> Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
>>> where ::= [/][@] | /
>>> SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
>>> make[1]: *** [universe.satellite-synonyms.lst] Error 255
>>> make[1]: Leaving directory `/opt/spacewalk/schema/spacewalk'
>>> make: *** [test-make-release]
Re: [Spacewalk-devel] PGPORT (installation issue using make)
Thanks Jeff,
Will give that a try tomorrow morning.
Vikram
On Thu, Jan 15, 2009 at 12:27 AM, Jeff Ortel wrote:
> Hey Vikram,
>
> I'd suggest you follow the developer setup instructions on the Spacewalk
> wiki:
>
> https://fedorahosted.org/spacewalk/wiki/DevelopmentWorkstationSetup
>
> ~jeff
>
>
> Vikram Rai wrote:
>
>> Hi,
>>
>> We were trying to install spacewalk using souce on Redhat 5 Enterprise
>> Server and after giving the command:
>>
>> make spacewalk-clean spacewalk-release TBS=USERS
>> SQLUSER=spacewalk/spacew...@xe
>>
>> We are getting the below error after the schema is created:
>> Attached is the log file of make command
>>
>> 1 row created.
>>
>>
>> Commit complete.
>>
>>
>> SQL_FILE
>> ---
>> rhnsat/quit.sql
>>
>> Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 -
>> Production
>>
>> SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jan 14 19:50:24 2009
>>
>> Copyright (c) 1982, 2005, Oracle. All rights reserved.
>>
>> ERROR:
>> ORA-12154: TNS:could not resolve the connect identifier specified
>>
>>
>> Enter user-name:
>> SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jan 14 19:50:24 2009
>>
>> Copyright (c) 1982, 2005, Oracle. All rights reserved.
>>
>> ERROR:
>> ORA-12154: TNS:could not resolve the connect identifier specified
>>
>>
>> Enter user-name: SP2-0306: Invalid option.
>> Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
>> where ::= [/][@] | /
>> SP2-0306: Invalid option.
>> Usage: CONN[ECT] [logon] [AS {SYSDBA|SYSOPER}]
>> where ::= [/][@] | /
>> SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
>> make[1]: *** [universe.satellite-synonyms.lst] Error 255
>> make[1]: Leaving directory `/opt/spacewalk/schema/spacewalk'
>> make: *** [test-make-release] Error 2
>>
>> I am sure this is not a tns issue as I am able to connect to the spacewalk
>> user from another terminal at the time the error is generated.
>>
>> Any suggestions as to what may be the cause of this, would be appreciated.
>>
>>
>> --
>> Regards
>>
>> Vikram Rai
>> Member Technical Team,
>> EnterpriseDB
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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 mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
