[2135] in Enterprise Print Delivery Team
Special meeting w/Bil, Theresa, George, Bob
daemon@ATHENA.MIT.EDU (Mary Ellen Bushnell)
Fri Dec 21 17:40:10 2001
Mime-Version: 1.0
Message-Id: <p0501040ab849554ccc26@[18.152.1.45]>
Date: Fri, 21 Dec 2001 17:39:59 -0500
To: printdel@MIT.EDU
From: Mary Ellen Bushnell <bushnell@MIT.EDU>
Content-Type: multipart/alternative; boundary="============_-1203148089==_ma============"
--============_-1203148089==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Here are my notes from today's meeting. We covered alot of ground.
Please read through and insert corrections then send to printdel.
DFL, forward to TR, Bil, George, Bob as you see fit.
Agenda topics:
- SAP to IPM process, esp. where Moira's place, and queue management.
- Matrix understanding
- Printdel's goals for authentication
- Naming conventions
- Desktop KLP
- Cost object and delivery address
- Production status
================================================
Production status
1. EP1 - delivery address doesn't yet appear on the banner page.
2. Pillage is production; Plunder is test.
3. SAP testing can be done on Pillage; Plunder is used to test system
upgrades and enhancements. There are three queues (the GL* queues)
on pillage for client testing. There needs to be another queue set up
on plunder for testing a new version of IPM.
4. The business continuity strategy is to be able to turn Plunder
into pillage. This is a disaster recovery procedure and needs to be
documentated.
Job Submission form
1. TR question: what's the connection between this page and the print job?
2. Issue: This page should confirm who is submitting the job.
QUEUE names and Moira
1. Where do queue names originate? LED currently creates logical
destination, printcap entries, and lpd perms "by hand" and sends the
request to Moira. Is this how it should be done? LED to discuss
w/Garry Zacheiss.
EP1-IPM is not yet in Moira. Should it be? NO! But no one else should
be able to create EP1-IPM in Moira. This should not be allowed to
happen. Queue names ending in -IPM should be limited to LED.
2. Queue data should live in MOIRA! Can info be shared between Moira
and IPM? How can this be handled most efficiently?
3. How does data in Moira relate to data in IPM?
-Moira's "restrict list" lists people who can print. LED is
putting this info in lpd perms on IPM.
-Moira's "lpc acl" lists who can manage queues, e.g., manager
of cao-print.
-Where should this info be stored? (LED) on IPM; (TR) in
Moira's lpc acl.
4. Who should be managing the GL* queues?
-Groups needing queue management privileges and level of
privilege (please correct this - I'm not sure we finished the
discussion):
System administrator - god-privileges
Computing Help Desk - local support
Business Liaison Team - local support
R3-admin - local support
End users - only their own queue
5. When print jobs are sent from members of "restrict list"
SAP spools print jobs to pillage. What happens to print jobs sent
from members of "restrict list"? (Print jobs not sent from restrict
list pass through just fine.) If the queue is restricted, then
mechanisms need to be defined to handle.
One strategy is to accept print coming in via lpr (instead of
flushing it) and put it in "retained" or similar so as not to have to
retrieve the job from the application server. REC to look into this.
LED - the problem of when administrator logs in as administrator.
LPRNG is strict; won't let a job through from someone not on
"restrict list" - and so it won't ever make it to Rocklyn's filter.
- FOR THOUGHT: If a problem occurs, then e-mail is sent to who
(submitter? BLT, other?) including statement of problem, how to fix,
who to call for help.
6. Queue naming conventions (Bil)
Need to look at all the queue names and devise a consistent naming
convention. Do it now.
7. KLP/KLPR is a big administrative headache for groups like CAO
where an administrator has to set up a desktop printer individually
on each users desktop (Bil)
8. Printdel's goals for authentication. (DFL)
Motivating factors are:
It's the direction in which the world is moving
It provides needed data to track usage and trends
Data is useful for INDIRECT cost recovery (allocating ASOP funds)
Data is essential to argue for new funds if business increases
This meeting w/resume on Monday, January 7, 10 am, W91 conference room.
--============_-1203148089==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
--></style><title>Special meeting w/Bil, Theresa, George,
Bob</title></head><body>
<div>Here are my notes from today's meeting. We covered alot of
ground. Please read through and insert corrections then send to
printdel. DFL, forward to TR, Bil, George, Bob as you see fit.</div>
<div><br></div>
<div>Agenda topics:</div>
<div>- SAP to IPM process, esp. where Moira's place, and queue
management.</div>
<div>- Matrix understanding</div>
<div>- Printdel's goals for authentication</div>
<div>- Naming conventions</div>
<div>- Desktop KLP</div>
<div>- Cost object and delivery address</div>
<div>- Production status</div>
<div>================================================</div>
<div><b>Production status</b></div>
<div>1. EP1 - delivery address doesn't yet appear on the banner
page.</div>
<div><br></div>
<div>2. Pillage is production; Plunder is test.</div>
<div><br></div>
<div>3. SAP testing can be done on Pillage; Plunder is used to test
system upgrades and enhancements. There are three queues (the
GL* queues) on pillage for client testing. There needs to be another
queue set up on plunder for testing a new version of IPM.</div>
<div><br></div>
<div>4. The business continuity strategy is to be able to turn Plunder
into pillage. This is a disaster recovery procedure and needs to be
documentated.</div>
<div><br></div>
<div><b>Job Submission form</b></div>
<div>1. TR question: what's the connection between this page and the
print job?</div>
<div><br></div>
<div>2. Issue: This page should confirm who is submitting the
job.</div>
<div><b><br></b></div>
<div><b>QUEUE names and Moira</b></div>
<div>1.<b> Where do queue names originate?</b> LED currently creates
logical destination, printcap entries, and lpd perms "by hand"
and sends the request to Moira. Is this how it should be done? LED to
discuss w/Garry Zacheiss.</div>
<div> </div>
<div>EP1-IPM is not yet in Moira. Should it be? NO! But no one else
should be able to create EP1-IPM in Moira. This should not be allowed
to happen. Queue names ending in -IPM should be limited to LED.</div>
<div><br></div>
<div>2.<b> Queue data should live in MOIRA!</b> Can info be
shared between Moira and IPM? How can this be handled most
efficiently?</div>
<div><br></div>
<div>3.<b> How does data in Moira relate to data in IPM?</b></div>
<div><x-tab>
</x-tab>-Moira's "restrict list" lists people who can print.
LED is putting this info in lpd perms on IPM.</div>
<div><x-tab>
</x-tab>-Moira's "lpc acl" lists who can manage queues,
e.g., manager of cao-print.</div>
<div><x-tab> </x-tab>-Where
should this info be stored? (LED) on IPM; (TR) in Moira's lpc
acl.</div>
<div><br></div>
<div>4.<b> Who should be managing the GL* queues?</b></div>
<div><x-tab> </x-tab>-Groups
needing queue management privileges and level of privilege (<b>please
correct this - I'm not sure we finished the discussion</b>):</div>
<div><x-tab> </x-tab>System
administrator - god-privileges</div>
<div><x-tab>
</x-tab>Computing Help Desk - local support</div>
<div><x-tab>
</x-tab>Business Liaison Team - local support</div>
<div><x-tab>
</x-tab>R3-admin - local support</div>
<div><x-tab> </x-tab>End
users - only their own queue</div>
<div><br></div>
<div>5.<b> When print jobs are sent from members of "restrict
list"</b></div>
<div>SAP spools print jobs to pillage. What happens to print jobs sent
from members of "restrict list"? (Print jobs not sent from
restrict list pass through just fine.) If the queue is restricted,
then mechanisms need to be defined to handle.</div>
<div><br></div>
<div>One strategy is to accept print coming in via lpr (instead of
flushing it) and put it in "retained" or similar so as not
to have to retrieve the job from the application server. REC to look
into this. LED - the problem of when administrator logs in as
administrator. LPRNG is strict; won't let a job through from someone
not on "restrict list" - and so it won't ever make it to
Rocklyn's filter.</div>
<div><br></div>
<div>-<b> FOR THOUGHT</b>: If a problem occurs, then e-mail is sent to
who (submitter? BLT, other?) including statement of problem, how to
fix, who to call for help.</div>
<div><br></div>
<div>6.<b> Queue naming conventions</b> (Bil)</div>
<div> Need to look at all the queue names and devise a
consistent naming convention. Do it now.</div>
<div><br></div>
<div>7.<b> KLP/KLPR is a big administrative headache</b> for groups
like CAO where an administrator has to set up a desktop printer
individually on each users desktop (Bil)</div>
<div><br></div>
<div>8.<b> Printdel's goals for authentication</b>. (DFL)</div>
<div> Motivating factors are:</div>
<div><x-tab> </x-tab>It's
the direction in which the world is moving</div>
<div><x-tab> </x-tab>It
provides needed data to track usage and trends</div>
<div><x-tab> </x-tab>Data is
useful for INDIRECT cost recovery (allocating ASOP funds)</div>
<div><x-tab> </x-tab>Data is
essential to argue for new funds if business increases</div>
<div><br></div>
<div>This meeting w/resume on Monday, January 7, 10 am, W91 conference
room.</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
</body>
</html>
--============_-1203148089==_ma============--
