config.sgml

关系型数据库 Postgresql 6.5.2

   and (to my surprise) it was
   incorporated into the <productname>Postgres</productname> distribution.
  </para>
  <Para>
   People often complain that locale doesn't work for them. 
   There are several common mistakes: 
   
   <ItemizedList>
    <ListItem>
     <Para>
      Didn't properly configure postgresql before compilation. 
      You must run configure with --enable-locale option to enable locale support. 
      Didn't setup environment correctly when starting postmaster. 
      You must define environment variables 
      <envar>LC_CTYPE</envar> and <envar>LC_COLLATE</envar> 
      before running postmaster
      because backend gets information about locale from environment. 
      I use following shell script
      (runpostgres): 
      
      <ProgramListing>
       #!/bin/sh
       
       export LC_CTYPE=koi8-r
       export LC_COLLATE=koi8-r
       postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'
      </ProgramListing>

      and run it from rc.local as 

      <ProgramListing>
       /bin/su - postgres -c "/home/postgres/runpostgres"
      </ProgramListing>

     </Para>
    </ListItem>
    <ListItem>
     <Para>
      Broken locale support in OS (for example, locale support in libc 
      under Linux several times has changed
      and this caused a lot of problems). Latest perl has also support of 
      locale and if locale is broken <command>perl -v</command> will
      complain something like: 
      
      <programlisting>
       8:17[mira]:~/WWW/postgres>setenv LC_CTYPE not_exist
       8:18[mira]:~/WWW/postgres>perl -v
       perl: warning: Setting locale failed.
       perl: warning: Please check that your locale settings:
       LC_ALL = (unset),
           LC_CTYPE = "not_exist",
           LANG = (unset)
       are supported and installed on your system.
       perl: warning: Falling back to the standard locale ("C").
      </programlisting>

     </Para>
    </ListItem>
    <ListItem>
     <Para>
      Wrong location of locale files!
      
      Possible locations include: 
      <filename>/usr/lib/locale</filename> 
      (Linux, Solaris), <filename>/usr/share/locale</filename> (Linux), 
      <filename>/usr/lib/nls/loc</filename> (DUX 4.0).
      
      Check <command>man locale</command> to find the correct location.
      Under Linux I did a symbolic link between <filename>/usr/lib/locale</filename> and
      <filename>/usr/share/locale</filename> to be sure that 
      the next libc will not break my locale.
     </Para>
    </ListItem>
   </ItemizedList>
  </para>

  <Sect2>
   <Title>What are the Benefits?</Title> 

   <Para>
    You can use ~* and order by operators for strings contain characters 
    from national alphabets. Non-english users
    definitely need that. If you won't use locale stuff just undefine 
    the USE_LOCALE variable. 
   </para>
  </sect2>

  <Sect2>
   <Title>What are the Drawbacks?</Title>
   
   <Para>
    There is one evident drawback of using locale - its speed! 
    So, use locale only if you really need it. 
   </para>
  </sect2>
 </sect1>
 
 <Sect1>
  <Title>Kerberos Authentication</Title>
  
  <Para>
   <productname>Kerberos</productname> is an industry-standard secure authentication
   system suitable for distributed computing over a public network.
  </para>

  <sect2>
   <title>Availability</title>
   
   <para>
    The
    <productname>Kerberos</productname>
    authentication system is not distributed with <Productname>Postgres</Productname>.  Versions of
    <productname>Kerberos</productname>
    are typically available as optional software from operating system
    vendors.  In addition, a source code distribution may be obtained through
    <ulink url="ftp://athena-dist.mit.edu">MIT Project Athena</ulink>.
   </para>
   <note>
    <para>
     You may wish to obtain the MIT version even if your
     vendor provides a version, since some vendor ports have been
     deliberately crippled or rendered non-interoperable with the MIT
     version.
    </para>
   </note>
   <para>
    Users located outside the United States of America and
    Canada are warned that distribution of the actual encryption code in
    <productname>Kerberos</productname>
    is restricted by U. S. Government export regulations.
   </para>
   <para>
    Inquiries regarding your <productname>Kerberos</productname> 
    should be directed to your vendor or
    <ulink url="[e-mail]">MIT Project Athena</ulink>.
    Note that <acronym>FAQL</acronym>s
    (Frequently-Asked Questions Lists) are periodically posted to the
    <ulink url="mailto:[e-mail]"><productname>Kerberos</productname> mailing list</ulink>
    (send
    <ulink url="mailto:[e-mail]">mail to subscribe</ulink>),
    and 
    <ulink url="news:comp.protocols.kerberos">USENET news group</ulink>.
   </para>
  </sect2>
  
  <sect2>
   <title>Installation</title>
   
   <para>
    Installation of 
    <productname>Kerberos</productname>
    itself is covered in detail in the 
    <citetitle>Kerberos Installation Notes</citetitle> .
    Make sure that the server key file (the <filename>srvtab</filename>
    or <filename>keytab</filename>)
    is somehow readable by the <productname>Postgres</productname> account.
   </para>
   <para>
    <Productname>Postgres</Productname> and its clients can be compiled to use 
    either Version 4 or Version 5 of the MIT
    <productname>Kerberos</productname>
    protocols by setting the 
    <envar>KRBVERS</envar>
    variable in the file <filename>src/Makefile.global</filename> to the
    appropriate value.  You can also change the location where
    <Productname>Postgres</Productname>
    expects to find the associated libraries, header files and its own
    server key file.
   </para>
   <para>
    After compilation is complete, <Productname>Postgres</Productname>
    must be registered as a <productname>Kerberos</productname>
    service.  See the
    <citetitle>Kerberos Operations Notes</citetitle>
    and related manual pages for more details on registering services.
   </para>
  </sect2>

  <sect2>
   <title>Operation</title>
   
   <para>
    After initial installation, <Productname>Postgres</Productname> 
    should operate in all ways as a normal
    <productname>Kerberos</productname>
    service.  For details on the use of authentication, see the
    <citetitle>PostgreSQL User's Guide</citetitle> reference sections
    for <application>postmaster</application>
    and <application>psql</application>.
   </para>
   <para>
    In the 
    <productname>Kerberos</productname>
    Version 5 hooks, the following assumptions are made about user
    and service naming:

    <itemizedlist>
     <listitem>
      <para>
       User principal names (anames) are assumed to
       contain the actual Unix/<Productname>Postgres</Productname> user name
       in the first component.
      </para>
     </listitem>
     <listitem>
      <para>
       The <Productname>Postgres</Productname> service is assumed to be have two components,
       the service name and a hostname, canonicalized as in Version 4 (i.e., with all domain
       suffixes removed).
      </para>
     </listitem>
     
    </itemizedlist>
   </para>
   <para>
    <table tocentry="1">
     <title>Kerberos Parameter Examples</title>
     <titleabbrev>Kerberos</titleabbrev>

     <tgroup cols="2">
      <thead>
       <row>
	<entry>
	 Parameter
	</entry>
	<entry>
	 Example
	</entry>
       </row>
      </thead>
      <tbody>
       <row>
	<entry>
	 user
	</entry>
	<entry>
	 [e-mail]
	</entry>
       </row>
       <row>
	<entry>
	 user
	</entry>
	<entry>
	 aoki/HOST=[e-mail]
	</entry>
       </row>	   
       <row>
	<entry>
	 host
	</entry>
	<entry>
	 postgres_dbms/[e-mail]
	</entry>
       </row>
      </tbody>
     </tgroup>
    </table>
   </para>
   <para>
    Support for Version 4 will disappear sometime after the production
    release of Version 5 by MIT.
   </para>
  </sect2>
 </sect1>
</chapter>