[2023] in Enterprise Print Delivery Team
Re: EP1
daemon@ATHENA.MIT.EDU (Theresa M Regan)
Mon Dec 10 14:10:55 2001
Message-Id: <5.0.2.1.2.20011210140742.03d91720@hesiod>
Date: Mon, 10 Dec 2001 14:10:51 -0500
To: "Lynne E. Durland" <durland@MIT.EDU>, "Lynne E. Durland" <durland@MIT.EDU>
From: Theresa M Regan <tregan@MIT.EDU>
Cc: "Huxley, Bil" <huxley@MIT.EDU>, Cana Lynn McCoy <cana@MIT.EDU>,
hesreq@MIT.EDU, printdel@MIT.EDU, caotech@MIT.EDU, R3-Print@MIT.EDU,
kelley@MIT.EDU, ops@MIT.EDU, Garry Zacheiss <zacheiss@MIT.EDU>
In-Reply-To: <5.0.2.1.2.20011210133041.035d4228@hesiod>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Lynne,
Any chance, I could meet with the team to discuss? I was under the
impression that in time IPM would be taking a feed from MOIRA. With that
in mind, we thought focusing on MOIRA as the central repository was helpful
to all involved in support "administrative printing".
Thanks,
Theresa
At 01:44 PM 12/10/2001 -0500, Lynne E. Durland wrote:
>Theresa,
>
>Yes the recap was very helpful. Now that I have had a chance to review
>this mail carefully and confirm some of the points with Dave Lambert, here
>is the printdel response.
>
>Based on this document I will stop cc'ing r3-print on SAP related requests
>to hesreq.
>
>On the restrict list portion, we have implemented a restrict list for the
>three queues in pillage, glmp, gltw, and glte, and would like to suggest a
>path for maintenance of these restrict lists. The process owner, for
>these queues, for example, Gil Emmons, should send mail to
>IPM-SYS@MITVMA.MIT.EDU, with the requested changes, which will be made by
>the appropriate maintainer of IPM. We would prefer this path, since
>pillage is not as tied to the Athena network as fiber or arbor-eater, and
>would require granting log on access to the production server, which we
>are trying to limit.
>
>On the other point about lpc acl, this is also covered by the granting of
>access to helpdesk levels on the web server, which has a slightly more
>friendly interface and would allow for instance, the CAOTech folks access
>to followup on print jobs for the glmp queue. This is also more useful as
>most of the queues in IPM are actually controlled by IPM rather than the
>LPRng software, which is acting as a gate into IPM.
>
>Hope this answers your concerns.
>
>Lynne
>
>For the Enterprise Print Delivery Team
>
>At 11:43 AM 12/6/2001, Theresa M Regan wrote:
>>Hi Lynne,
>>
>>thanks...
>>
>>Based on the last few exchanges, it seems that a recap of current process
>>may be helpful and possibly, alleviate a step or two. Example: e-mail
>>to r3-print may not necessary if the queue is included in the current
>>process. Also, there are two dimensions of MOIRA's printer
>>characteristics, we rely on from time-to-time that may be helpful to
>>mention: restrict list and LPC ACL
>>
>>Current Process
>>------------------------
>>
>>Athena Print Services will create a printer definition in MOIRA and for
>>administrative users mark it as SAP. (Generally, these requests are sent
>>to "hesreq". Some requests come via Computing-Help.)
>>
>>Today, any printer requests for the administrative community and/or SAP
>>are created in MOIRA and propagated to the print servers: arbor-eater or
>>fiber. (After printer definitions are created, hesreq receives revisions
>>from time-to-time and these revisions are reflected in the daily process.)
>>
>>Nightly, the printer definitions from arbor-eater and fiber are sent to
>>windsurf.
>>
>>R3-print is notified when the "new" or "deleted" print queue data arrives
>>at windsurf.
>>
>>R3-print is notified, again, after the printer definitions have been
>>updated on all of the R/3 servers.
>>
>>Since Garry has confirmed that the nightly feed will include pillage and
>>plunder when designated SAP, this appears to fall nicely into the
>>process. (I should go back and at the windsurf e-mail notifications to
>>be sure that we clearly note the IPM queues.)
>>
>>If people agree with the above steps, then, we can alleviate the r3-print
>>e-mail when sending requests to hesreq.
>>
>>Once the printer definitions are defined on the servers, they are
>>configured within SAP R/3 (SF2) and transported to all remaining SAP R/3
>>environments.
>>
>>There are a few Departments who prefer that only certain people print to
>>their printers. These departments maintain an Athena list and it is
>>noted within the MOIRA printer definition. It is reference as "Restrict List".
>>
>>After discussion at R3-Admin, we wish to recommend that IPM print queues
>>consider using this approach, as well. Example: glmp would have a list
>>glmp-print-restrict and its administrator would be the key Process
>>Owner. The Process Owner could delegate the maintenance, if desired.
>>
>>(My experience with APS is that the print request arrives at the server
>>and after a comparison with the list, it is either printed or
>>deleted. How the IPM implementation would handle requests from an
>>unauthorized person is a "printdel" question.)
>>
>>Another MOIRA printer characteristic, we have used on a limited
>>basis... is who may manage print queues? For those Departments with
>>technical staff and lots of printers, we have set the attribute: LPC
>>ACL For CAO, it is managed through the list caoprint
>>
>>Hopefully, I have captured the printer/print queue process accurately and
>>reasonably clearly. If others wish to clarify or expand, please feel
>>free. Once printdel has had time to consider the restrict list approach,
>>possibly, we could focus on its implementation for the 4 queues in
>>question: glmp, glte, gltw, (missing one).
>>
>>Thanks,
>>Theresa
>>
>>
>>
>>
>>At 09:06 AM 12/6/2001 -0500, Lynne E. Durland wrote:
>>>Theresa,
>>>
>>>All IPM print queues are in Moira, and the agreement was that when a
>>>request is sent to hesreq if it is an SAP related printer that will be
>>>noted in the request and the mail cc'd to r3-print.
>>>
>>>Lynne
>>>
>>>At 04:42 AM 12/6/2001 -0500, Theresa M Regan wrote:
>>>>Hi Garry,
>>>>
>>>>Thank-you for chiming in and confirming earlier decisions about IPM
>>>>queues defined in MOIRA. Although it differs from my understanding, it
>>>>is probably best to just move forward at this juncture.
>>>>
>>>>Peter, we have been able to confirm that the print queue is defined
>>>>properly in MOIRA and that it was included in the file fed from MOIRA
>>>>to windsurf. When you have a moment, would you glance at the file from
>>>>MOIRA and confirm that EP1 is included and with the necessary
>>>>information to define the printer definitions for SAP?
>>>>
>>>>PRINTDEL, in light of Garry's information... that only print queues
>>>>designated as "SAP" will be fed from MOIRA...
>>>>
>>>> 1) will all IPM print queues be defined in MOIRA?
>>>>
>>>> 2) if yes, and they are not intended for SAP R/3, how will they
>>>> be noted?
>>>>
>>>>Thanks,
>>>>Theresa
>>>>
>>>>
>>>>At 07:23 PM 12/5/2001 -0500, Garry Zacheiss wrote:
>>>>> >> It is my understanding that the MOIRA feed to windsurf would be
>>>>> expanded
>>>>> >> to include the IPM servers, as well. I believe, it would simplify
>>>>> >> people's understanding of what happens to administrative print queues
>>>>> >> entered into MOIRA if they follow the current, daily process from
>>>>> MOIRA
>>>>> >> to windsurf.
>>>>>
>>>>> We've already had this discussion, and I have the old email to prove
>>>>>it. :-)
>>>>>
>>>>> The last time this came up, what we agreed on was this:
>>>>>
>>>>> 1.)Queues on pillage/plunder that would be SAP queues would
>>>>> be created in moira as type "SAP", and would be in
>>>>> the file sent to windsurf.
>>>>>
>>>>> 2.)We would *not* send windsurf all queues on pillage/plunder.
>>>>>
>>>>>This is detailed in a message I sent, included below.
>>>>>
>>>>>Is it the case that the conditions I specified then are still
>>>>>sufficient, and we just haven't been following this procedure, or that
>>>>>we now no longer wish to follow this process?G
>>>>>
>>>>>[53020] daemon@ATHENA.MIT.EDU (Lynne E.
>>>>>Durland) Ops_Projects 12/23/00 09:04 (90 lines)
>>>>>Subject: Re: pillage/plunder info from moira to asst
>>>>>Message-Id: <4.3.2.7.2.20001223090207.00b3be28@po12.mit.edu>
>>>>>Date: Sat, 23 Dec 2000 09:02:26 -0500
>>>>>To: Garry Zacheiss <zacheiss@mit.edu>
>>>>>From: "Lynne E. Durland" <durland@MIT.EDU>
>>>>>Cc: Garry Zacheiss <zacheiss@mit.edu>, "Peter B. Kelley" <kelley@mit.edu>,
>>>>> ops@mit.edu, printdel@mit.edu, asst@mit.edu
>>>>>In-Reply-To: <200012222027.PAA00885@hodge-podge.mit.edu>
>>>>>Mime-Version: 1.0
>>>>>Content-Type: multipart/alternative;
>>>>> boundary="=====================_1225111==_.ALT"
>>>>>
>>>>>--=====================_1225111==_.ALT
>>>>>Content-Type: text/plain; charset="us-ascii"; format=flowed
>>>>>
>>>>>Thanks Garry,
>>>>>
>>>>>This sounds good to me.
>>>>>
>>>>>Lynne
>>>>>
>>>>>At 03:27 PM 12/22/2000 -0500, Garry Zacheiss wrote:
>>>>> > Ok, I've made those changes. The queue "retipm" is now type SAP
>>>>> >in moira, and it and its duplex queue are the only queues on
>>>>> >pillage/plunder in the file that will be generated and shipped to
>>>>> >fleagle.
>>>>> >
>>>>> > I've left admissions and w91-109-blahblahblah in moira as type
>>>>> >'IPM' for now; this doesn't actually have any significance anymore, but
>>>>> >I'd like to leave myself a hook for any future expansion and
>>>>> >development.
>>>>> >
>>>>> > Ops: I've checked in a change to sapprint.gen reverting the
>>>>> >previous revision, and installed it on the moira server.
>>>>> >
>>>>> > hesreq folk: Slight modification to what was said previously:
>>>>> > From now on, if an queue on pillage/plunder is to be in SAP, the mail
>>>>> >sent to hesreq should specify that, and should be entered in moira as
>>>>> >type 'SAP'. Other queues on pillage/plunder should be type 'IPM'.
>>>>> >
>>>>> > Bug me if you have questions.
>>>>> >
>>>>> >Garry
>>>>>
>>>>>--[53020]-- (pref = [53009])
>>>
>>>Lynne E. Durland
>>>Information Systems
>>>Database Services Team
>>>W91-109
>>>P:258-5857
>>>E: durland@mit.edu
>>>H: 603-421-0940
>>>H: KB1FEM
>>>
>>>
>>>"When speaking to a Bear of Very Little Brain, remember that long words
>>>may Bother Him."
>>> --A.A. Milne
>
>Lynne E. Durland
>Information Systems
>Database Services
>W91-109
>O: 617-258-5857
>C: 617-293-8091
>H: KB1FEM
>
>"When one door of happiness closes, another opens; but often we look so
>long at the closed door that we do not see the one which has been opened
>for us."
>
> --Helen Keller
