[Printing-architecture] directory structure / file name conventions

[Printing-architecture] directory structure / file name conventions

[Fujinaka, Todd]

After studying the Filesystem Hierarchy Standard, I would like to
propose two additional directories (/opt/openprinting/share/ppd and
/usr/local/share/ppd) for addition to the single PPD directory
structure.

Section 4.1 describes the purpose of /usr in the following manner:

"/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between various
FHS-compliant hosts and must not be written to. Any information that is
host-specific or varies with time is stored elsewhere."

In usage, this has been used to mean that an OS can update
/usr/share/ppd/*, but a 3rd-party vendor must not write to
/usr/share/ppd/*. This severely limits the ability for vendors to add
their own PPD files unless they are accepted into the base install of an
FHS-conforming system.

The appropriate place for 3rd-party vendors is the /opt hierarchy.
Section 3.13.1 describes the purpose of /opt as follows:

"/opt is reserved for the installation of add-on application software
packages.

"A package to be installed in /opt must locate its static files in a
separate /opt/<package> or /opt/<provider> directory tree, where
<package> is a name that describes the software package and <provider>
is the provider's LANANA registered name."

I would suggest that a "provider" name of openprinting be used so any
additional vendor PPD files would be stored in:
/opt/openprinting/share/ppd/*

Additionally, the system administrator is allowed access to /usr/local
which is described in section 4.8.1 with the purpose:

"The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being overwritten
when the system software is updated. It may be used for programs and
data that
are shareable amongst a group of hosts, but not found in /usr.

"Locally installed software must be placed within /usr/local rather than
/usr unless it is being installed to replace or upgrade software in
/usr."

Therefore I would suggest an additional /usr/local/share/ppd/* for the
use of any system administrators.

In summary, I suggest expanding the locations for PPD file from
/usr/share/ppd to also include /opt/openprinting/share/ppd and
/usr/local/share/ppd. This follows the FHS standard while still
retaining the OpenPrinting group's requirement of strictly defining the
location of PPD files.

Thanks,
Todd Fujinaka

Re: [Printing-architecture] directory structure / file name conventions

[Till Kamppeter]

Fujinaka, Todd wrote:
> After studying the Filesystem Hierarchy Standard, I would like to
> propose two additional directories (/opt/openprinting/share/ppd and
> /usr/local/share/ppd) for addition to the single PPD directory
> structure.
> 
> Section 4.1 describes the purpose of /usr in the following manner:
> 
> "/usr is the second major section of the filesystem. /usr is shareable,
> read-only data. That means that /usr should be shareable between various
> FHS-compliant hosts and must not be written to. Any information that is
> host-specific or varies with time is stored elsewhere."
> 
> In usage, this has been used to mean that an OS can update
> /usr/share/ppd/*, but a 3rd-party vendor must not write to
> /usr/share/ppd/*. This severely limits the ability for vendors to add
> their own PPD files unless they are accepted into the base install of an
> FHS-conforming system.
> 
> The appropriate place for 3rd-party vendors is the /opt hierarchy.
> Section 3.13.1 describes the purpose of /opt as follows:
> 
> "/opt is reserved for the installation of add-on application software
> packages.
> 
> "A package to be installed in /opt must locate its static files in a
> separate /opt/<package> or /opt/<provider> directory tree, where
> <package> is a name that describes the software package and <provider>
> is the provider's LANANA registered name."
> 
> I would suggest that a "provider" name of openprinting be used so any
> additional vendor PPD files would be stored in:
> /opt/openprinting/share/ppd/*
> 
> Additionally, the system administrator is allowed access to /usr/local
> which is described in section 4.8.1 with the purpose:
> 
> "The /usr/local hierarchy is for use by the system administrator when
> installing software locally. It needs to be safe from being overwritten
> when the system software is updated. It may be used for programs and
> data that
> are shareable amongst a group of hosts, but not found in /usr.
> 
> "Locally installed software must be placed within /usr/local rather than
> /usr unless it is being installed to replace or upgrade software in
> /usr."
> 
> Therefore I would suggest an additional /usr/local/share/ppd/* for the
> use of any system administrators.
> 
> In summary, I suggest expanding the locations for PPD file from
> /usr/share/ppd to also include /opt/openprinting/share/ppd and
> /usr/local/share/ppd. This follows the FHS standard while still
> retaining the OpenPrinting group's requirement of strictly defining the
> location of PPD files.
> 
> Thanks,
> Todd Fujinaka

Some questions:

- Should we also have similar alternatives for /usr/lib/print-drivers/?
Theoretically driver could be put anywhere with absolute paths in PPDs,
but for enhanced security environments it is important to have them at
determined places and also for the drivers themselves we must be FHS
compliant.

- Can we use /opt/printing instead of /opt/openprinting, as the
drivers/PPDs do not come from FSG OpenPrinting.

- "/usr is shareable, read-only data" for me would only mean that while
running programs this should not be written, but software packages can
be installed here. Is there another clause in the FHS telling that only
software of the OS distribution can be installed here?

- There is still one problem with integrating these directories with
CUPS: If a printer needs a special backend for the low-level
communication, like for example the "hp" CUPS backend for the HP
printers used with HPLIP, dropping them into something like
/usr/lib/print-drivers/<supplier>/ will not work, as CUPS looks only in
/usr/lib/cups/backend and absolute paths as device URI are not possible.
 How can one solve this problem.

   Till

Re: [Printing-architecture] directory structure / file name conventions

[Michael Sweet]

Till Kamppeter wrote:
> Fujinaka, Todd wrote:
>> After studying the Filesystem Hierarchy Standard, I would like to
>> propose two additional directories (/opt/openprinting/share/ppd and
>> /usr/local/share/ppd) for addition to the single PPD directory
>> structure.
>>
>> Section 4.1 describes the purpose of /usr in the following manner:
>>
>> "/usr is the second major section of the filesystem. /usr is shareable,
>> read-only data. That means that /usr should be shareable between various
>> FHS-compliant hosts and must not be written to. Any information that is
>> host-specific or varies with time is stored elsewhere."
>>
>> In usage, this has been used to mean that an OS can update
>> /usr/share/ppd/*, but a 3rd-party vendor must not write to
>> /usr/share/ppd/*. This severely limits the ability for vendors to add
>> their own PPD files unless they are accepted into the base install of an
>> FHS-conforming system.
>>
>> The appropriate place for 3rd-party vendors is the /opt hierarchy.
>> Section 3.13.1 describes the purpose of /opt as follows:
>>
>> "/opt is reserved for the installation of add-on application software
>> packages.
>>
>> "A package to be installed in /opt must locate its static files in a
>> separate /opt/<package> or /opt/<provider> directory tree, where
>> <package> is a name that describes the software package and <provider>
>> is the provider's LANANA registered name."
>>
>> I would suggest that a "provider" name of openprinting be used so any
>> additional vendor PPD files would be stored in:
>> /opt/openprinting/share/ppd/*
>>
>> Additionally, the system administrator is allowed access to /usr/local
>> which is described in section 4.8.1 with the purpose:
>>
>> "The /usr/local hierarchy is for use by the system administrator when
>> installing software locally. It needs to be safe from being overwritten
>> when the system software is updated. It may be used for programs and
>> data that
>> are shareable amongst a group of hosts, but not found in /usr.
>>
>> "Locally installed software must be placed within /usr/local rather than
>> /usr unless it is being installed to replace or upgrade software in
>> /usr."
>>
>> Therefore I would suggest an additional /usr/local/share/ppd/* for the
>> use of any system administrators.
>>
>> In summary, I suggest expanding the locations for PPD file from
>> /usr/share/ppd to also include /opt/openprinting/share/ppd and
>> /usr/local/share/ppd. This follows the FHS standard while still
>> retaining the OpenPrinting group's requirement of strictly defining the
>> location of PPD files.
>>
>> Thanks,
>> Todd Fujinaka
> 
> Some questions:
> 
> - Should we also have similar alternatives for /usr/lib/print-drivers/?
> Theoretically driver could be put anywhere with absolute paths in PPDs,
> but for enhanced security environments it is important to have them at
> determined places and also for the drivers themselves we must be FHS
> compliant.
> 
> - Can we use /opt/printing instead of /opt/openprinting, as the
> drivers/PPDs do not come from FSG OpenPrinting.
> 
> - "/usr is shareable, read-only data" for me would only mean that while
> running programs this should not be written, but software packages can
> be installed here. Is there another clause in the FHS telling that only
> software of the OS distribution can be installed here?
> 
> - There is still one problem with integrating these directories with
> CUPS: If a printer needs a special backend for the low-level
> communication, like for example the "hp" CUPS backend for the HP
> printers used with HPLIP, dropping them into something like
> /usr/lib/print-drivers/<supplier>/ will not work, as CUPS looks only in
> /usr/lib/cups/backend and absolute paths as device URI are not possible.
>  How can one solve this problem.

How about this:

1. Add support for /opt/printing and /usr/local/printing for vendor
    and local printing file installation.

2. All CUPS-specific files go under /opt/printing/cups or
    /usr/local/printing/cups, as follows:

        {path}/backend/vendor.appname
        {path}/filter/vendor.appname
        {path}/mime/vendor.appname.types
        {path}/mime/vendor.appname.convs
        {path}/monitor/vendor.appname
        {path}/notifier/vendor.appname

    Vendors should probably symlink their installed files from
    /opt/vendor to /opt/printing/cups/*/vendor.*.

3. We will extend CUPS so that ServerBin can contain a list of
    directories that are scanned, and a new MimePath directive which
    lists the locations of MIME .types and .convs files, with the
    default being ServerRoot.

    Linux distributors can add configure options like:

        --with-serverbin="/usr/lib/cups:/opt/printing/cups:
                          /usr/local/printing/cups"
        --with-mimepath="/etc/cups:/opt/printing/cups/mime:
                         /usr/local/printing/cups/mime"

    to populate these directives with what they want (we can make
    those the default, too...)

4. Non-CUPS printing systems can support CUPS drivers/etc. via
    some sort of compatibility layer or wrapper script.  For example,
    Solaris LP can have an interface script which runs the CUPS
    filter chain.

Thoughts?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com

Re: [Printing-architecture] directory structure / file name conventions

[Fujinaka, Todd]

>-----Original Message-----
>From: Till Kamppeter [mailto:till.kamppeter@gmx.net]
>Some questions:
>
>- Should we also have similar alternatives for /usr/lib/print-drivers/?
>Theoretically driver could be put anywhere with absolute paths in PPDs,
>but for enhanced security environments it is important to have them at
>determined places and also for the drivers themselves we must be FHS
>compliant.

Yes. I was just focusing on the PPD files because I thought I should get
the idea out first.

>- Can we use /opt/printing instead of /opt/openprinting, as the
>drivers/PPDs do not come from FSG OpenPrinting.

It's really supposed to be /opt/<vendor>. I think /opt/openprinting
would be in the spirit of that, but /opt/printing would require some
discussion with the FHS.

>- "/usr is shareable, read-only data" for me would only mean that while
>running programs this should not be written, but software packages can
>be installed here. Is there another clause in the FHS telling that only
>software of the OS distribution can be installed here?

This is just the understanding I have from Debian developers who are
held to the FHS standard. They told me that /usr is read-only, but you
can write to it to update things that are there already. It's
questionable whether new packages can be written there, but an OS vendor
can probably get away with installing things in /usr on their own OS.

>- There is still one problem with integrating these directories with
>CUPS: If a printer needs a special backend for the low-level
>communication, like for example the "hp" CUPS backend for the HP
>printers used with HPLIP, dropping them into something like
>/usr/lib/print-drivers/<supplier>/ will not work, as CUPS looks only in
>/usr/lib/cups/backend and absolute paths as device URI are not
possible.
> How can one solve this problem.


Todd