Re: [Spacewalk-devel] Reason db_name value change in, /etc/rhn/rhn.conf?
Bo Maryniuk wrote: % On Fri, Sep 07, 2012 at 02:46:34PM +0200, Jan Pazdziora wrote: % I'm not sure I correctly understand what you ask about but the % oracle_get_database_answers % % The /etc/rhn/rhn.conf has nothing to do with *Oracle* database at all. % It is *generic* config and database back-end can be even IBM DB2 one % day. The configuration keys in the rhn.conf belongs to the RHN % configuration, not to the Oracle database! ... % ...by acquiring the values. But even that, putting URI inside in % only one particular syntax is more like hard-coded ad-hoc because % somebody % had a personal problem somewhere. In some cases it can be a different % syntax, like: % % user/password@//host:port/database % % or: % % (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host) % (PORT=port)))(CONNECT_DATA=(SERVER=DEDICATED) % (SERVICE_NAME=database)));User Id=user;Password=password; % % or: % % user/password@host/service:dedicated/database; % % or: % % //$host/$database?user=$userpassword=$passwordssl=true % % etc. Hi Bo, Could you give us more context of the real world issue you are trying to solve? Thanks regards, -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason db_name value change in, /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 04:10:13PM +0200, Jan Pazdziora wrote: On Fri, Sep 07, 2012 at 03:54:25PM +0200, Bo Maryniuk wrote: The /etc/rhn/rhn.conf has nothing to do with *Oracle* database at all. Right, besides providing database type and connect information, which for Oracle backend turns out to be ... Oracle connection specification. :-P One more time: /etc/rhn/rhn.conf has nothing to do with *Oracle* vendor. It has everything to do with providing a *generic* information for database connectivity, which can be Oracle or PostgreSQL (as of today). The problem is that built tools around the Spacewalk now needs to be also changed to specifically parse the URI and also determine in if/else fashion is it URI or just a name, if some other fields left empty etc. Users, that are using PostgreSQL version now have to worry about Oracle-specific hardcoded ad-hocs and the documentation now needs to contain trash like If you use Oracle, then and if PostgreSQL, then.. Instead of just work as before. So the question still remains: what was the REASON to change what is working rock-solid for years? And another sub-question: why it is not called db_uri (because it *is* URI)? -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer There are 10 types of people in the world: those who understand binary, and those who don't. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Reason db_name value change in /etc/rhn/rhn.conf?
Hi! I am wondering what was the reason to make this very awkward change in 1.7 by using URI in db_name in the /etc/rhn/rhn.conf other than because now our Java can connect different way? My opinion on that: 1. This is called *db_name*. So let it be the *name*. 2. This is not called db_uri as it is right now for some reasons. 3. It duplicates values from db_host and db_port, making them obsolete and/or irrelevant. 4. It adds mess and noise to the configuration: if we already have the URI, why the heck we still have host and port defined? 5. If your particular place in your particular software supposed to use URI instead of plain name, then why not construct it there, instead of parse-and-reconstruct anyway, because if other code don't need to use this notation? 6. It is still not called db_uri. Because host:port//name is not a *name* but resource location! So the semantics are wrong anyway now. The bottom line is that if this particular syntax needs to be there, then better add one more parameter db_uri. IOW: http://goo.gl/e8l8v I would vote to change it back as it was in 1.2 version. -- Bo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason db_name value change in /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 02:22:56PM +0200, Bo Maryniuk wrote: I am wondering what was the reason to make this very awkward change in 1.7 by using URI in db_name in the /etc/rhn/rhn.conf other than because now our Java can connect different way? I'm not sure I correctly understand what you ask about but the oracle_get_database_answers was refactored for 1.3. The explanation is right in that commit message of mine: commit 11df63a4baf949231d1fb52fabf41c64b0753c77 Author: Jan Pazdziora jpazdzi...@redhat.com Date: Tue Jan 18 16:25:24 2011 +0100 Refactored oracle_get_database_answers. We do not want to ask for username and password before we know what database we talk to. Also, we no longer create/change /etc/tnsnames.ora. The db-name in answer file can either refer to service name at db-host (//db-host(:db-port)/db-name) or to a service name specified in tnsnames.ora. This allows the user to set anything in their tnsnames.ora before running spacewalk-setup (think RAC and any advanced options) and just use it. For similar reason, db-protocol is no longer supported. My opinion on that: 1. This is called *db_name*. So let it be the *name*. One of the ways of naming the connect target is eznames, which is exactly what this is using. If you prefer, just setup whatever you want in tnsnames.ora and just use that -- the logic in the setup will then use the name from tnsnames if it figures out it can connect that way. 3. It duplicates values from db_host and db_port, making them obsolete and/or irrelevant. Right. We just leave them empty. We could just not set them up at all in that case. Patch welcome. 4. It adds mess and noise to the configuration: if we already have the URI, why the heck we still have host and port defined? We need to support them for PostgreSQL. -- 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] Reason db_name value change in, /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 02:46:34PM +0200, Jan Pazdziora wrote: I'm not sure I correctly understand what you ask about but the oracle_get_database_answers The /etc/rhn/rhn.conf has nothing to do with *Oracle* database at all. It is *generic* config and database back-end can be even IBM DB2 one day. The configuration keys in the rhn.conf belongs to the RHN configuration, not to the Oracle database! just setup whatever you want in tnsnames.ora tnsnames.ora is a part of Oracle database. Again, /etc/rhn/rhn.conf has nothing to do with a particular database vendor. RHN configuration is a place, where *generic* information about *any* database connectivity is specified. A specific URI strings for specific drivers on specific database vendors must be handled inside the particular application. What if I am connecting my Windows Server .Net written app over ODBC to Postgres? -- I am constructing my own URI inside. And now I need specifically parse the URI? Why so?.. Right. We just leave them empty. [...] We need to support them for PostgreSQL. I can spot here severe logical problem: We just leave them empty vs We need them to support $FOO database. This only proves than /etc/rhn/rhn.conf file is *generic* place for *varius* and different components. That directly means that hard-coding specific URI over db_name variable that belongs to RHN configuration syntax is just a very bad idea. As a result, other components need to parse this URI, remove all the host:port information and extract only a database name. Why? The bottom line is that now these keys are not unified and can mean anything. I would understand if RHN config would do something like: db_host = foo.bar.com db_port = 5432 db_name = blahblah db_uri = //$db_host:$db_port/$db_name ...by acquiring the values. But even that, putting URI inside in only one particular syntax is more like hard-coded ad-hoc because somebody had a personal problem somewhere. In some cases it can be a different syntax, like: user/password@//host:port/database or: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host) (PORT=port)))(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=database)));User Id=user;Password=password; or: user/password@host/service:dedicated/database; or: //$host/$database?user=$userpassword=$passwordssl=true etc. -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer We are experiencing system trouble -- do not adjust your terminal! ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason db_name value change in, /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 03:54:25PM +0200, Bo Maryniuk wrote: The /etc/rhn/rhn.conf has nothing to do with *Oracle* database at all. Right, besides providing database type and connect information, which for Oracle backend turns out to be ... Oracle connection specification. :-P has nothing to do with a particular database vendor. RHN configuration is a place, where *generic* information about *any* database connectivity is specified. Right. For Oracle, both I_AM_NAME_DEFINED_IN_TNSNAMES_ORA and //host.domain:1522/DATABASE_ON_THAT_HOST are valid strings that can be used in lieu of connect specification. Or database name if you will. application. What if I am connecting my Windows Server .Net written app over ODBC to Postgres? -- I am constructing my own URI inside. You have Spacewalk ported to .Net? I can spot here severe logical problem: We just leave them empty ... for Oracle. If PostgreSQL had the same unified way of specifying the database connection target across all three stacks we use, we would not need db_host and db_port at all -- these were introduced specifically for PostgreSQL. The beautiful generic design of that configuration file had to give way to reality. As a result, other components need to parse this URI, remove all the host:port information and extract only a database name. Why? Why would they? All three stacks we use in Spacewalk use that db_name value directly, IIRC. No parsing needed. Why would Spacewalk care about the database name at all? Can you show the part of Spacewalk (code) where having the connect information stored this way (as opposed to creating and overriding /etc/tnsnames.ora which completely prevented people to have any advanced setups) poses a problem? had a personal problem somewhere. In some cases it can be a different syntax, like: user/password@//host:port/database or: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host) (PORT=port)))(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=database)));User Id=user;Password=password; or: user/password@host/service:dedicated/database; or: //$host/$database?user=$userpassword=$passwordssl=true It can. It might even work with the code as is. What's wrong with that? -- 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
