proxy/installer/c2s.xml | 347 ----------------------
proxy/installer/configure-proxy.sh | 3
proxy/installer/sm.xml | 379 -------------------------
proxy/installer/spacewalk-proxy-installer.spec | 4
proxy/proxy/spacewalk-proxy.spec | 2
5 files changed, 2 insertions(+), 733 deletions(-)
New commits:
commit 2a53041fa4ce870cab91a732a9368b5cac49af89
Author: Miroslav Suchý <msuchy(a)redhat.com>
Date: Wed Feb 24 17:08:53 2010 +0100
566124 - do not distribute jabber configuration file
use spacewalk-setup-jabberd to edit jabberd conf file
diff --git a/proxy/installer/c2s.xml b/proxy/installer/c2s.xml
deleted file mode 100644
index fbbff1b..0000000
--- a/proxy/installer/c2s.xml
+++ /dev/null
@@ -1,347 +0,0 @@
-<!-- c2s configuration -->
-<c2s>
- <!-- Our ID on the network (default: c2s) -->
- <id>c2s</id>
-
- <!-- The process ID file. comment this out if you don't need to know
- to know the process ID from outside the process (eg for control
- scripts) -->
- <pidfile>/var/run/jabberd/jabberd-c2s.pid</pidfile>
-
- <!-- Router connection configuration -->
- <router>
- <!-- IP/port the router is waiting for connections on -->
- <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 -->
- <port>5347</port> <!-- default: 5347 -->
-
- <!-- Username/password to authenticate as -->
- <user>jabberd</user> <!-- default: jabberd -->
- <pass>secret</pass> <!-- default: secret -->
-
- <!-- File containing a SSL certificate and private key to use when
- setting up an encrypted channel with the router. If this is
- commented out, or the file can't be read, no attempt will be
- made to establish an encrypted channel with the router. -->
-
- <pemfile>/etc/jabberd/server.pem</pemfile>
-
- <!-- Router connection retry -->
- <retry>
- <!-- If the connection to the router can't be established at
- startup, we should try again this many times before exiting.
- Use -1 to retry indefinitely. [default: 3] -->
- <init>3</init>
-
- <!-- If we lost the connection to the router during normal
- operation (ie we've successfully connected to the router in
- the past), we should try to reconnect this many times before
- exiting. Use -1 to retry indefinitely. [default: 3] -->
- <lost>3</lost>
-
- <!-- Sleep for this many seconds before trying attempting a
- reconnect. [default: 2] -->
- <sleep>2</sleep>
- </retry>
- </router>
-
- <!-- Log configuration - type is "syslog", "file" or
"stdout" -->
- <log type='syslog'>
- <!-- If logging to syslog, this is the log ident -->
- <ident>jabberd/c2s</ident>
-
- <!-- If logging to syslog, this is the log facility
- (local0 - local7) [default: local3] -->
- <facility>local3</facility>
-
- <!-- If logging to file, this is the filename of the logfile -->
- <!--
- <file>/var/log/jabberd/c2s.log</file>
- -->
- </log>
-
- <!-- Local network configuration -->
- <local>
- <!-- Who we identify ourselves as. This should correspond to the
- ID (host) that the session manager thinks it is. You can
- specify more than one to support virtual hosts, as long as you
- have additional session manager instances on the network to
- handle those hosts. The realm attribute specifies the auth/reg
- or SASL authentication realm for the host. If the attribute is
- not specified, the realm will be selected by the SASL
- mechanism, or will be the same as the ID itself. Be aware that
- users are assigned to a realm, not a host, so two hosts in the
- same realm will have the same users.
- If no realm is specified, it will be set to be the same as the
- ID. -->
- <id>${session.hostname}</id>
- <!-- <id realm='company'>localhost</id> -->
-
- <!-- IP address to bind to (default: 0.0.0.0) -->
- <ip>0.0.0.0</ip>
-
- <!-- Port to bind to, or 0 to disable unencrypted access to the
- server (default: 5222) -->
- <port>5222</port>
-
- <!-- File containing a SSL certificate and private key for client
- connections. If this is commented out, clients will not be
- offered the STARTTLS stream extension -->
- <pemfile>/etc/jabberd/server.pem</pemfile>
-
- <!-- Require STARTTLS. If this is enabled, clients must do STARTTLS
- before they can authenticate. Until the stream is encrypted,
- all packets will be dropped. -->
- <!--
- <require-starttls/>
- -->
-
- <!-- Older versions of jabberd support encrypted client connections
- via an additional listening socket on port 5223. If you want
- this (required to allow pre-STARTTLS clients to do SSL),
- uncomment this -->
- <!--
- <ssl-port>5223</ssl-port>
- -->
- </local>
-
- <!-- Input/output settings -->
- <io>
- <!-- Maximum number of file descriptors. Note that the number of
- possible connections will be slightly less than this, because
- c2s itself can use up five on its own, and auth/reg modules may
- need a few also. If the supply of file descriptors is
- exhausted, new incoming connections will be denied.
- (default: 1024) -->
- <max_fds>1024</max_fds>
-
- <!-- Rate limiting -->
- <limits>
- <!-- Maximum bytes per second - if more than X bytes are sent in Y
- seconds, connection is throttled for Z seconds. The format
- is:
-
- <bytes seconds='Y' throttle='Z'>X</bytes>
-
- Default Y is 1, default Z is 5. set X to 0 to disable. -->
- <bytes>0</bytes>
-
- <!-- Maximum connects per second - if more than X connects are
- attempted from a single IP in Y seconds, that IP is throttled
- for Z seconds. The format is:
-
- <connects seconds='Y' throttle='Z'>X</connects>
-
- Default Y is 5, default Z is 5. set X to 0 to disable. -->
- <connects>0</connects>
- </limits>
-
- <!-- IP-based access controls. If a connection IP matches an allow
- rule, the connection will be accepted. If a connecting IP
- matches a deny rule, the connection will be refused. If the
- connecting IP does not match any rules, or it matches both an
- allow and a deny rule, the contents of the <order/> option
- determines what happens. -->
- <access>
- <!-- Rule check order (default: allow,deny)
-
- allow,deny - Check allow rules, then check deny rules.
- Allow by default.
- deny,allow - Check deny rules, then check allow rules.
- Deny by default. -->
- <order>allow,deny</order>
-
- <!-- Allow a network. If the mask isn't specified, it defaults to
- 255.255.255.255 (ie allow onle the specified IP) -->
- <!--
- <allow ip='127.0.0.0' mask='255.0.0.0'/>
- -->
-
- <!-- Allow a single host -->
- <!--
- <allow ip='12.34.56.78'/>
- -->
-
- <!-- Deny a network or a host -->
- <!--
- <deny ip='127.0.0.1' mask='255.0.0.0'/>
- <deny ip='87.65.43.21'/>
- -->
- </access>
-
- <!-- Timed checks -->
- <check>
- <!-- Interval between checks.
-
- Open client connections will be checked every n seconds, and
- the following checks applied.
-
- 0 disables all checks. (default: 0) -->
- <interval>0</interval>
-
- <!-- Idle connection checks.
-
- Connections that have not sent data for longer than this many
- seconds will be dropped.
-
- 0 disables idle timeouts. (default: 0) -->
- <idle>0</idle>
-
- <!-- Keepalives.
-
- Connections that have not sent data for longer than this many
- seconds will have a single whitespace character sent to them.
- This will force the TCP connection to be closed if they have
- disconnected without us knowing about it.
-
- 0 disables keepalives. (default: 0) -->
- <keepalive>0</keepalive>
-
- </check>
-
- </io>
-
- <!-- Authentication/registration database configuration -->
- <authreg>
- <!-- Backend module to use -->
- <module>db</module>
-
- <!-- Registration configuration -->
- <register>
- <!-- Account registration is enabled by default (provided the
- auth/reg module in use supports it). Comment this out to
- disable. -->
- <enable/>
-
- <!-- Human-readable instructions to be returned to client when
- registration is requested. -->
- <instructions>Enter a username and password to register with this
server.</instructions>
-
- <!-- Password change only. When registration is disabled, it may
- still be useful to allow clients to change their password. If
- you want this, uncomment this when you disable registration. -->
- <!--
- <password/>
- -->
- </register>
-
- <!-- Available authentication mechanisms -->
- <mechanisms>
-
- <!-- These are the traditional Jabber authentication mechanisms.
- Comment out any that you don't want to be offered to clients.
- Note that if the auth/reg module does not support one of
- these mechanisms, then it will not be offered regardless of
- whether or not it is enabled here.
-
- Similarly, if <zerok/> is disabled, then zero-knowledge data
- will not be created when a user is registered. -->
- <traditional>
- <plain/>
- <digest/>
- <zerok/>
- </traditional>
-
- <!-- SASL authentication mechanisms. Comment out any that you
- don't want to be offered to clients. Again, if the auth/reg
- module does not support one of these mechanisms, then it will
- not be offered. -->
- <sasl>
- <plain/>
- <digest-md5/>
- <!--
- <anonymous/>
- -->
- </sasl>
-
- </mechanisms>
-
- <!-- MySQL module configuration -->
- <mysql>
- <!-- Database server host and port -->
- <host>localhost</host>
- <port>3306</port>
-
- <!-- Database name -->
- <dbname>jabberd2</dbname>
-
- <!-- Database username and password -->
- <user>jabberd2</user>
- <pass>secret</pass>
- </mysql>
-
- <!-- PostgreSQL module configuration -->
- <pgsql>
- <!-- Database server host and port -->
- <host>localhost</host>
- <port>5432</port>
-
- <!-- Database name -->
- <dbname>jabberd2</dbname>
-
- <!-- Database username and password -->
- <user>jabberd2</user>
- <pass>secret</pass>
- </pgsql>
-
- <!-- Berkeley DB module configuration -->
- <db>
- <!-- Directory to store database files under -->
- <path>/var/lib/jabberd</path>
-
- <!-- Synchronize the database to disk after each write. If you
- disable this, database accesses may be faster, but data may
- be lost if jabberd crashes. -->
- <sync/>
- </db>
-
- <!-- LDAP module configuration -->
- <ldap>
- <!-- LDAP server host and port (default: 389) -->
- <host>ldap.example.com</host>
- <port>389</port>
-
- <!-- Use LDAP v3 if possible. If disabled, v2 will be used.
- Encryption options are only available if v3 is enabled. -->
- <!--
- <v3/>
- -->
-
- <!-- Encryption. If enabled, this will create an encrypted channel
- to the LDAP server using the LDAP STARTTLS mechanism. -->
- <!--
- <starttls/>
- -->
-
- <!-- Encryption. If enabled, this will create an encrypted channel
- to the server using the old-style "ldaps://" mechanism. It is
- recommended that you use <starttls/> instead of this. -->
- <!--
- <ssl/>
- -->
-
- <!-- DN to bind as for searches. If unspecified, the searches
- will be done anonymously. -->
- <!--
- <binddn>cn=Directory Manager</binddn>
- <bindpw>secret</bindpw>
- -->
-
- <!-- LDAP attribute that holds the user ID (default: uid) -->
- <uidattr>uid</uidattr>
-
- <!-- base DN of the tree. You should specify a DN for each
- authentication realm declared in the <local/> section above,
- by using the realm attribute. -->
- <basedn realm='company'>o=Company.com</basedn>
- <basedn>o=Example Corp.</basedn>
- </ldap>
-
- <!-- Pipe module configuration -->
- <pipe>
- <!-- Program to execute -->
- <exec>/usr/bin/pipe-auth.pl</exec>
- </pipe>
-
- </authreg>
-
-</c2s>
diff --git a/proxy/installer/configure-proxy.sh b/proxy/installer/configure-proxy.sh
index afd2de7..b1ccf9c 100755
--- a/proxy/installer/configure-proxy.sh
+++ b/proxy/installer/configure-proxy.sh
@@ -349,8 +349,7 @@ fi
SQUID_SIZE=$(df -P /var/spool/squid | awk '{a=$4} END {printf("%d", a * 60
/ 100 / 1024)}')
ln -sf /etc/pki/spacewalk/jabberd/server.pem /etc/jabberd/server.pem
-sed "s/\${session.hostname\}/$HOSTNAME/g" < $DIR/c2s.xml >
$JABBERD_DIR/c2s.xml
-sed "s/\${session.hostname\}/$HOSTNAME/g" < $DIR/sm.xml >
$JABBERD_DIR/sm.xml
+/usr/bin/spacewalk-setup-jabberd --macros "hostname:$HOSTNAME"
sed "s|cache_dir ufs /var/spool/squid 15000 16 256|cache_dir ufs /var/spool/squid
$SQUID_SIZE 16 256|g" \
< $DIR/squid.conf > $SQUID_DIR/squid.conf
sed -e "s|\${session.ca_chain:/usr/share/rhn/RHNS-CA-CERT}|$CA_CHAIN|g" \
diff --git a/proxy/installer/sm.xml b/proxy/installer/sm.xml
deleted file mode 100644
index 1330cfa..0000000
--- a/proxy/installer/sm.xml
+++ /dev/null
@@ -1,379 +0,0 @@
-<!-- Session manager configuration -->
-<sm>
- <!-- Our ID on the network. Users will have this as the domain part of
- their JID. If you want your server to be accessible from other
- Jabber servers, this ID must be resolvable by DNS.s
- (default: localhost) -->
- <id>${session.hostname}</id>
-
- <!-- The process ID file. comment this out if you don't need to know
- to know the process ID from outside the process (eg for control
- scripts) -->
- <pidfile>/var/run/jabberd/jabberd-sm.pid</pidfile>
-
- <!-- Router connection configuration -->
- <router>
- <!-- IP/port the router is waiting for connections on -->
- <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 -->
- <port>5347</port> <!-- default: 5347 -->
-
- <!-- Username/password to authenticate as -->
- <user>jabberd</user> <!-- default: jabberd -->
- <pass>secret</pass> <!-- default: secret -->
-
- <!-- File containing a SSL certificate and private key to use when
- setting up an encrypted channel with the router. If this is
- commented out, or the file can't be read, no attempt will be
- made to establish an encrypted channel with the router. -->
- <!--
- <pemfile>/etc/jabberd/server.pem</pemfile>
- -->
- <!-- Router connection retry -->
- <retry>
- <!-- If the connection to the router can't be established at
- startup, we should try again this many times before exiting.
- Use -1 to retry indefinitely. [default: 3] -->
- <init>3</init>
-
- <!-- If we lost the connection to the router during normal
- operation (ie we've successfully connected to the router in
- the past), we should try to reconnect this many times before
- exiting. Use -1 to retry indefinitely. [default: 3] -->
- <lost>3</lost>
-
- <!-- Sleep for this many seconds before trying attempting a
- reconnect. [default: 2] -->
- <sleep>2</sleep>
- </retry>
- </router>
-
- <!-- Log configuration - type is "syslog", "file" or
"stdout" -->
- <log type='syslog'>
- <!-- If logging to syslog, this is the log ident -->
- <ident>jabberd/sm</ident>
-
- <!-- If logging to syslog, this is the log facility
- (local0 - local7) [default: local3] -->
- <facility>local3</facility>
-
- <!-- If logging to file, this is the filename of the logfile -->
- <!--
- <file>/var/log/jabberd/sm.log</file>
- -->
- </log>
-
- <!-- Storage database configuration -->
- <storage>
- <!-- By default, we use the MySQL driver for all storage -->
- <driver>db</driver>
-
- <!-- Its also possible to explicitly list alternate drivers for
- specific data types. -->
- <!-- Store vcards in a PostgreSQL database instead -->
- <!--
- <driver type='vcard'>pgsql</driver>
- -->
-
- <!-- MySQL driver configuration -->
- <mysql>
- <!-- Database server host and port -->
- <host>localhost</host>
- <port>3306</port>
-
- <!-- Database name -->
- <dbname>jabberd2</dbname>
-
- <!-- Database username and password -->
- <user>jabberd2</user>
- <pass>secret</pass>
-
- <!-- Transacation support. If this is commented out, transactions
- will be disabled. This might make database accesses faster,
- but data may be lost if jabberd crashes.
-
- This will need to be disabled if you are using a MySQL
- earlier than v3.23.xx, as transaction support did not appear
- until this version. -->
- <transactions/>
- </mysql>
-
- <!-- PostgreSQL driver configuration -->
- <pgsql>
- <!-- Database server host and port -->
- <host>localhost</host>
- <port>5432</port>
-
- <!-- Database name -->
- <dbname>jabberd2</dbname>
-
- <!-- Database username and password -->
- <user>jabberd2</user>
- <pass>secret</pass>
-
- <!-- Transacation support. If this is commented out, transactions
- will be disabled. This might make database accesses faster,
- but data may be lost if jabberd crashes. -->
- <transactions/>
- </pgsql>
-
- <!-- Berkeley DB driver configuration -->
- <db>
- <!-- Directory to store database files under -->
- <path>/var/lib/jabberd</path>
-
- <!-- Synchronize the database to disk after each write. If you
- disable this, database accesses may be faster, but data may
- be lost if jabberd crashes. -->
- <sync/>
- </db>
- </storage>
-
- <!-- Access control information -->
- <aci>
- <!-- The JIDs listed here will get access to all restricted
- functions, regardless of restrictions further down -->
- <acl type='all'>
- <jid>admin@localhost</jid>
- </acl>
-
- <!-- These JIDs can send broadcast messages (announce, motd) -->
- <!--
- <acl type='broadcast'>
- <jid>nocstaff1@localhost</jid>
- <jid>nocstaff2@localhost</jid>
- </acl>
- -->
-
- <!-- These JIDs will receive messages addressed to the sm itself
- (help requestes and such) -->
- <!--
- <acl type='messages'>
- <jid>support@localhost</jid>
- </acl>
- -->
-
- <!-- These JIDs can discover active user/session information -->
- <!--
- <acl type='disco'>
- <jid>webstatus@localhost</jid>
- </acl>
- -->
- </aci>
-
- <!-- Module chain configuration
-
- Modules listed in a chain are called in the order specified at
- the appropriate time for that chain (assuming that the module
- knows how to work with that chain; otherwise it simply ignores
- it).
-
- Removing a module from these lists will stop the module being
- called, even if its compiled into the server.
-
- Serveral modules have a presence in more than one chain. It is
- possible to remove a module from one chain but not others, but
- this may cause strange behaviour. Make sure you know what you're
- doing. -->
- <modules>
-
- <!-- sess-start. The modules in this chain are called when a session
- is first started (usually on request by c2s as part of the
- authentication process). This is normally used to load
- per-session data. -->
- <chain id='sess-start'/>
-
- <!-- sess-end. The modules in this chain are called just before a
- session is destroyed (after the client has disconnected). -->
- <chain id='sess-end'>
- <module>iq-last</module> <!-- update logout time -->
- </chain>
-
- <!-- in-sess. The modules in this chain are called when a packet
- arrives from an active user session. Note that this chain is
- also responsible for delivering packets to their destinations -
- this is usually handled by the "deliver" module. -->
- <chain id='in-sess'>
- <module>validate</module> <!-- validate packet type -->
- <module>privacy</module> <!-- manage privacy lists -->
- <module>roster</module> <!-- handle roster get/sets and
s10ns -->
- <module>vacation</module> <!-- manage vacation settings
-->
- <module>iq-vcard</module> <!-- store and retrieve the
user's vcard -->
- <module>iq-private</module> <!-- manage the user's private
data store -->
- <module>disco</module> <!-- respond to agents requests
from sessions -->
- <module>offline</module> <!-- if we're coming online
for the first time, deliver queued messages -->
- <module>announce</module> <!-- deliver motd -->
- <module>presence</module> <!-- process and distribute
presence updates -->
- <module>deliver</module> <!-- deliver packets with full
jids directly -->
- </chain>
-
- <!-- out-sess. The modules in this chain are called just before a
- packet is delivered to an active user session. -->
- <chain id='out-sess'/>
-
- <!-- in-router. The modules in this chain are called when a packet
- arrives from the router (ie another component or s2s), but
- before any processing is done. This is a good place to filter
- incoming packets. -->
- <chain id='in-router'>
- <module>session</module> <!-- perform session actions as
required by c2s -->
- <module>validate</module> <!-- validate packet type -->
- <module>presence</module> <!-- drop incoming presence if
user not online -->
- <module>privacy</module> <!-- filter incoming packets based
on privacy rules -->
- </chain>
-
- <!-- out-router. The modules in this chain are called just before a
- packet is delivered to the router (destined for another
- component or s2s). This is a good place to filter outgoing
- packets. -->
- <chain id='out-router'>
- <module>privacy</module> <!-- filter outgoing packets based
on privacy rules -->
- </chain>
-
- <!-- pkt-sm. The modules in this chain are called when a packet
- arrives that is addressed to the session manager itself (ie the
- to JID has no node part). This is normally used to provide
- session-manager-wide services (like service discovery). -->
- <chain id='pkt-sm'>
- <module>iq-last</module> <!-- return the server uptime
-->
- <module>iq-time</module> <!-- return the current server
time -->
- <module>iq-version</module> <!-- return the server name and
version -->
- <module>disco</module> <!-- build the disco list; respond
to disco queries -->
- <module>announce</module> <!-- send broadcast messages
(announce, motd, etc) -->
- <module>help</module> <!-- resend sm messages to
administrators -->
- <module>echo</module> <!-- echo messages sent to /echo
-->
- </chain>
-
- <!-- pkt-user. The modules in this chain are called when a packet
- arrives that is address to a specific user. Note that this
- chain is also responsible for delivering packets to user
- sessions as appropriate - this is usually handled by the
- "deliver" module. -->
- <chain id='pkt-user'>
- <module>roster</module> <!-- handle s10n responses -->
- <module>presence</module> <!-- process and distribute
incoming presence from external entities -->
- <module>iq-vcard</module> <!-- grab user vcards -->
- <module>deliver</module> <!-- deliver the packet to an
active session if we can -->
- <module>vacation</module> <!-- send vacation messages
-->
- <module>offline</module> <!-- save messages and s10ns for
later -->
- <module>disco-publish</module> <!-- handle disco publishes;
return information about user sessions -->
- <module>iq-last</module> <!-- return time since last logout
-->
- </chain>
-
- <!-- pkt-router. The modules in this chain are called when a
- special-purpose packet arrives from the router (eg domain
- advertisements). -->
- <chain id='pkt-router'>
- <module>session</module> <!-- take sessions offline their
c2s disappears -->
- <module>disco</module> <!-- query new components for
service information -->
- </chain>
-
- <!-- user-load. The modules in this chain are called to load
- per-user data. This will happen before a user can be used (ie
- before a session is created). -->
- <chain id='user-load'>
- <module>active</module> <!-- get active status -->
- <module>roster</module> <!-- load the roster and trust
list -->
- <module>privacy</module> <!-- load privacy lists -->
- <module>disco-publish</module> <!-- load published information
-->
- <module>vacation</module> <!-- load vacation settings
-->
- </chain>
-
- <!-- user-create. The modules in this chain are called when a user
- creation request is received (usually from c2s as part of a
- registration request). This initialises any per-user data. -->
- <chain id='user-create'>
- <module>active</module> <!-- activate new users -->
- <module>template-roster</module> <!-- populate roster from template
-->
- </chain>
-
- <!-- user-delete. The modules in this chain are called when a user
- deletion request is received (usually from c2s as part of a
- registration removal request). This deletes all data that may
- have been previously created for the user during normal
- operation. -->
- <chain id='user-delete'>
- <module>active</module> <!-- deactivate users -->
- <module>announce</module> <!-- delete motd data -->
- <module>disco-publish</module> <!-- delete published information
-->
- <module>offline</module> <!-- bounce queued messages
-->
- <module>privacy</module> <!-- delete privacy lists -->
- <module>roster</module> <!-- delete roster -->
- <module>vacation</module> <!-- delete vacation settings
-->
- <module>iq-last</module> <!-- delete last logout time
-->
- <module>iq-private</module> <!-- delete private data -->
- <module>iq-vcard</module> <!-- delete vcard -->
- </chain>
-
- </modules>
-
- <!-- Service discovery configuration -->
- <discovery>
-
- <!-- Service identity. these specify the category, type and name of
- this service that will be included in discovery information
- responses. -->
- <identity>
- <category>server</category> <!-- default: server -->
- <type>im</type> <!-- default: im -->
- <name>Jabber IM server</name> <!-- default: Jabber IM server
-->
- </identity>
-
- <!-- The discovery module can respond to jabber:iq:agents queries
- for compatibility with older clients. Comment this out to
- disable this. -->
- <agents/>
-
- <!-- Static service list.
-
- The discover module can discover disco-capable services
- automatically as they come online. Most legacy services,
- however, will not support discovery. In order to get them to
- appear in disco/agents lists returned to the client, they
- should be listed here.
-
- Note that if a disco-capable service with the same name as one
- listed below comes online, the information it provides will
- override the information listed below.
-
- The "category" and "type" attributes, and the list of
supported
- namespaces are only used for agents compatibility. If you have
- disabled this above, you may omit them. -->
- <items>
-
- <!-- example entry for a user directory -->
- <!--
- <item category='service' type='jud'
jid='users.jabber.org' name='Jabber User Directory'/>
- -->
-
- <!-- example entry for a groupchat (conference) service -->
- <!--
- <item category='conference' type='public'
jid='conference.jabber.org' name='Text conferencing'/>
- -->
-
- </items>
-
- </discovery>
-
- <!-- User options -->
- <user>
- <!-- By default, users must explicitly created before they can start
- a session. The creation process is usually triggered by a c2s
- component in response to a client registering a new user.
-
- Enableing this option will make it so that a user create will be
- triggered the first time a non-existant user attempts to start
- a session. This is useful if you already have users in an
- external authentication database (eg LDAP) and you don't want
- them to have to register. -->
- <auto-create/>
-
- <!-- Templates. If defined, the contents of these files will be
- stored in the users data store when they are created. -->
- <template>
- <!--
- <roster>/etc/jabberd/templates/roster.xml</roster>
- -->
- </template>
- </user>
-
-</sm>
diff --git a/proxy/installer/spacewalk-proxy-installer.spec
b/proxy/installer/spacewalk-proxy-installer.spec
index ec47d76..82b11c9 100644
--- a/proxy/installer/spacewalk-proxy-installer.spec
+++ b/proxy/installer/spacewalk-proxy-installer.spec
@@ -53,8 +53,6 @@ mkdir -p $RPM_BUILD_ROOT/%{_mandir}/man8
mkdir -p $RPM_BUILD_ROOT/%{_usr}/sbin
mkdir -p $RPM_BUILD_ROOT/%{_usr}/share/rhn/installer
install -m 755 -d $RPM_BUILD_ROOT%{defaultdir}
-install -m 644 c2s.xml $RPM_BUILD_ROOT%{defaultdir}
-install -m 644 sm.xml $RPM_BUILD_ROOT%{defaultdir}
install -m 644 cluster.ini $RPM_BUILD_ROOT%{defaultdir}
install -m 644 squid.conf $RPM_BUILD_ROOT%{defaultdir}
install -m 644 rhn.conf $RPM_BUILD_ROOT%{defaultdir}
@@ -72,8 +70,6 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%dir %{defaultdir}
-%{defaultdir}/c2s.xml
-%{defaultdir}/sm.xml
%{defaultdir}/cluster.ini
%{defaultdir}/squid.conf
%{defaultdir}/rhn.conf
diff --git a/proxy/proxy/spacewalk-proxy.spec b/proxy/proxy/spacewalk-proxy.spec
index 7a55e77..62200d0 100644
--- a/proxy/proxy/spacewalk-proxy.spec
+++ b/proxy/proxy/spacewalk-proxy.spec
@@ -37,7 +37,7 @@ Requires: %{name}-html
%else
Requires: spacewalk-proxy-selinux
%endif
-Requires: jabberd
+Requires: jabberd spacewalk-setup-jabberd
Requires: httpd
Requires: sos
Requires(preun): initscripts