Print servers + ip printing + scoadmin = brain haemorrage
Clint Zikesch
I'm talking to you Bill V! :)
Although I have had a few years experience with print servers and Novell
I would like to configure ip printing direct from our UNIX servers.
This is proving to be a little annoying.
First question:
It doesn't seem likely that when I add a new printer using scoadmin
under SCO 5.0.5 it should immediately disappear.. Therefore even though
I have added the release supplements I assume there is more to be done.
Can someone point me in the right direction on this? (I am using rlpconf
for the time being and finding it quite adequate)
Second question:
I have successfully used my DHCP server to assign addresses to most of
the print servers.. some refused their IP addresses and are assigned
manually until I get around to finding out why.. We have HP, Intel and
'Intelligent 3P100' print servers of varying antiquity.
In order to avoid stair stepping in text files (mostly dot-matrix
printers and text file based output) the manufacturers recommend to
print using the host name <whatever> and the printer:
HP - TEXT or TEXT1,TEXT2,TEXT3 for 3 port servers
Intel - LPT1_TEXT,LPT2_TEXT for 2 port servers
Intelligent 3P100 - not up to this one yet
Of course that makes alot of printers with the same name for a queue,
well we can't have that can we!
So I have created the queues according to a convention and manually
altered the printcap file so the 'rp' entry reflects the correct setting
for the correct port on the host in question. Believe it or not I
thought this was clever as i now had separate queues for each printer.
Obviously my understanding the of the vagaries of UNIX printing is not
yet perfected.
I have tested several queues successfully and I was happy happy joy joy
for about half an hour.. to my horror when I was figuring out how to
maintain queues I noticed that lpstat now shows a list of printers
according to the entries in the 'rp' section and the whole thing appears
rather daunting to maintain. This can't be right and there must be a
better way. I have an idea that a filter would get me out of this mess
but as I haven't had the good fortune to find one suitable yet can
someone confirm or deny the validity of this option?
As I have only about another 9 days to get this and innumerable other
glitches fixed up I would appreciate any and all guidance and assistance
in this matter.
In short.. it seems to work fine but I need to be able to maintain the
working system with some precision as the 150 simultaneous users are
likely to want their print jobs squished eventually, given there about
100 printers or more it could take a while to find the right one like
this.
Here is a copy of the printcap file so far if it's of any help..
# Remote Line Printer (BSD format)
dit4mv:\
:lp=:rm=dit4mv:rp=dit4mv_TEXT:sd=/usr/spool/lpd/dit4mv:
adm4mv:\
:lp=:rm=adm4mv:rp=TEXT:sd=/usr/spool/lpd/adm4mv:
prd4mv:\
:lp=:rm=prd4mv:rp=TEXT:sd=/usr/spool/lpd/prd4mv:
mel4p:\
:lp=:rm=mel4p:rp=TEXT:sd=/usr/spool/lpd/mel4p:
dye4mv:\
:lp=:rm=dye4mv:rp=TEXT:sd=/usr/spool/lpd/dye4mv:
whshp1-1:\
:lp=:rm=whshp1:rp=TEXT1:sd=/usr/spool/lpd/whshp1-1:
whshp1-2:\
:lp=:rm=whshp1:rp=TEXT2:sd=/usr/spool/lpd/whshp1-2:
whshp1-3:\
:lp=:rm=whshp1:rp=TEXT3:sd=/usr/spool/lpd/whshp1-3:
dyein1-1:\
:lp=:rm=dyein1:rp=LPT1_TEXT:sd=/usr/spool/lpd/dyein1-1:
finin1-1:\
:lp=:rm=finin1:rp=LPT1_TEXT:sd=/usr/spool/lpd/finin1-1:
fshin1-1:\
:lp=:rm=fshin1:rp=LPT1_TEXT:sd=/usr/spool/lpd/fshin1-1:
purin1-1:\
:lp=:rm=purin1:rp=LPT1_TEXT:sd=/usr/spool/lpd/purin1-1:
admin1-1:\
:lp=:rm=admin1:rp=LPT1_TEXT:sd=/usr/spool/lpd/admin1-1:
admin1-2:\
:lp=:rm=admin1:rp=LPT2_TEXT:sd=/usr/spool/lpd/admin1-2:
melin1-1:\
:lp=:rm=melin1:rp=LPT1_TEXT:sd=/usr/spool/lpd/melin1-1:
melin1-2:\
:lp=:rm=melin1:rp=LPT2_TEXT:sd=/usr/spool/lpd/melin1-2:
prdin1-1:\
:lp=:rm=prdin1:rp=LPT1_TEXT:sd=/usr/spool/lpd/prdin1-1:
prdin1-2:\
:lp=:rm=prdin1:rp=LPT2_TEXT:sd=/usr/spool/lpd/prdin1-2:
qlyin1-1:\
:lp=:rm=qlyin1:rp=LPT1_TEXT:sd=/usr/spool/lpd/qlyin1-1:
Anyone who helps me will get a free lunch if they happen to be passing
through Albury which is on the border of NSW and Victoria in Australia!
Thanks in advance
Clint (remove the spaces)
czikesch@ mtgl.com.au
Jeff Liebermann
wrote:
>First question:
>It doesn't seem likely that when I add a new printer using scoadmin
>under SCO 5.0.5 it should immediately disappear.. Therefore even though
>I have added the release supplements I assume there is more to be done.
>Can someone point me in the right direction on this? (I am using rlpconf
>for the time being and finding it quite adequate)
Yawn. OSS497B fixes this problem. OSS497A doesn't.
Also see:
My network printers configured with lpd are missing
in Printer Manager.
http://www.sco.com/cgi-bin/ssl_reference?109737
for the fast fix.
>Second question:
Please don't mix more than one question per posting. It tends to create
confusion.
>I have successfully used my DHCP server to assign addresses to most of
>the print servers.. some refused their IP addresses and are assigned
>manually until I get around to finding out why.. We have HP, Intel and
>'Intelligent 3P100' print servers of varying antiquity.
I'm confused. Any particular model of HP? The HP25xx series print
servers need to have bootp enabled in the MIO setup and doesn't support
DHCP, only bootp. No clue on Intel or whatever an "Intelligent 3P100"
print server.
>In order to avoid stair stepping in text files (mostly dot-matrix
>printers and text file based output) the manufacturers recommend to
>print using the host name <whatever> and the printer:
I'm confused. What you've apparently done is created a different printer
name for each "feature" of the printer. That will work and your
description of how it plays is correct. If you're going to use lpr as a
print formatter, then you do it either that way, or run it all through a
filter. Since you're only interested in dealing with staircase output,
try a pipe through:
/usr/lib/lponlcr
which will add a CR for every LF that it's fed. However, 100 printers
are going to require 100 individual entries, no matter how you configure
it.
>In short.. it seems to work fine but I need to be able to maintain the
>working system with some precision as the 150 simultaneous users are
>likely to want their print jobs squished eventually, given there about
>100 printers or more it could take a while to find the right one like
>this.
Allow me to put in a plug for "netcat" which just does a "cat" to any
random network port. This will give you a single interface to the
network printers, regardless of port flavour or ASCII filter
denomination. See:
http://www.cruzio.com/~jeffl/sco/lp/
The idea is to use the stock SCO print spooler and spooler scripts. This
allows you can imbed all manner of disgusting and misplace printer
controls in the command line such as:
lp -d printer_name -ol filename
which switches the printer to landscape if you're using the HPLaserJet
spooler script. Such control and features are missing in lpr/lpd.
[x]news [x]email [ ]mailing list
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Jean-Pierre Radley
| On Wed, 06 Oct 1999 19:09:33 +1000, Clint Zikesch <czik...@mtgl.com.au>
| wrote:
|
| >First question:
| >It doesn't seem likely that when I add a new printer using scoadmin
| >under SCO 5.0.5 it should immediately disappear.. Therefore even though
| >I have added the release supplements I assume there is more to be done.
| >Can someone point me in the right direction on this? (I am using rlpconf
| >for the time being and finding it quite adequate)
|
| Yawn. OSS497B fixes this problem. OSS497A doesn't.
Oss497c obsoletes the prior versions (and my be installed without
removing either oss497a or oss497b).
--
Jean-Pierre Radley <j...@jpr.com> XC/XT Custodian Sysop, CompuServe SCOForum
Bill Vermillion
<czik...@mtgl.com.au> wrote:
>Hello kindly SCO experts! I'm talking to you Bill V! :)
There are two Bill V's here. Which one of this are you directing
your message toward.
(My email link disappeard during an ISP reorg. I was the last one
to be notified - and I had just over 24 hours notice. It's all
being cued elsewhere, but it will be a day or two to get outgoing
running again because of other important things).
>Second question: I have successfully used my DHCP server to assign
>addresses to most of the print servers.. some refused their
>IP addresses and are assigned manually until I get around to
>finding out why..
How are you going to find which server is handling what part
if you have DHCP running. DHCP is great for allocation of
addresses from PC's but is not pretty for devices such as servers
or printers.
Others have already made significant comments, so I'll not
add more to this at the moment.
Bill
--
Bill Vermillion bv @ wjv.com
Jazzmanian
>My network printers configured with lpd are missing
>in Printer Manager.
>http://www.sco.com/cgi-bin/ssl_reference?109737 for the fast fix.
This may be a silly question, but this was not a problem in 5.04 right ?
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Clint Zikesch
software which fixed the duplicate queue name problem. Does anyone know how
the queues work under the Intel proprint setup? there are no notes or
documentation that I can find on this. I have posed the question on the
Intel forum and will let you know if I find out.
Probably will do the same for HP servers but that's a job for the morning..
thanks for all help offered.
if anyone would like to know the printcap entries look like this:
admin1_1|admin1_1-on-parallel-port-1:\
:lp=admin1_1:\
:intl_n=xxx.xxx.xxx.xxx:\
:intl_p=3001:\
:intl_text=enable:\
admin1_2|admin1_2-on-parallel-port-2:\
:lp=admin1_2:\
:intl_n=xxx.xxx.xxx.xxx:\
:intl_p=3002:\
:intl_text=enable:\
intl_n is the host.. the config software forces you to use the ip address
and I will try changing it to hostname in the morning.
intl_p is the port signifying the parallel port (use 2501 for serial)
Regards
Clint
czikesch@ mtgl.com.au
Chaos reigns within.
Reflect, repent, and reboot.
Order shall return.
Tom Parsons
| In case anyone is interested I have installed the Intel configuration
| software which fixed the duplicate queue name problem. Does anyone know how
| the queues work under the Intel proprint setup? there are no notes or
| documentation that I can find on this. I have posed the question on the
| Intel forum and will let you know if I find out.
| Probably will do the same for HP servers but that's a job for the morning..
| thanks for all help offered.
|
| if anyone would like to know the printcap entries look like this:
|
| admin1_1|admin1_1-on-parallel-port-1:\
| :lp=admin1_1:\
| :intl_n=xxx.xxx.xxx.xxx:\
| :intl_p=3001:\
| :intl_text=enable:\
|
| admin1_2|admin1_2-on-parallel-port-2:\
| :lp=admin1_2:\
| :intl_n=xxx.xxx.xxx.xxx:\
| :intl_p=3002:\
| :intl_text=enable:\
|
| intl_n is the host.. the config software forces you to use the ip address
| and I will try changing it to hostname in the morning.
| intl_p is the port signifying the parallel port (use 2501 for serial)
This is not a programming questions, reply only to comp.unix.sco.misc.
Are you sure you want to suffer this torture? :-) Before you go much
further, look at netcat. http://www.cruzio.com/~jeffl/sco/lp/
It is configurable, easy to use, makes your printers act and look like
local spooler printers plus can be used to eliminate the annoying form feed
that some Intel print servers force upon you.
--
==========================================================================
Tom Parsons t...@tegan.com Sysop, SCOForum-CompuServe
==========================================================================
Jeff Liebermann
On Thu, 07 Oct 1999 20:03:03 +1000, Clint Zikesch <czik...@mtgl.com.au>
wrote:
>In case anyone is interested I have installed the Intel configuration
>software which fixed the duplicate queue name problem. Does anyone know how
>the queues work under the Intel proprint setup?
I'm interested. In fact, I'm always interested in what people do to
solve problems that are posted.
Sorry. No clue on the Intel proprint. Nothing useful on their web site.
I can't tell if you saw my previous reply to your question.
However, I do have some dumb questions that revolve around whatever you
are attempting to accomplish.
1. Do you really have 100 different print servers that this OSR5 box
needs to spool to or merely 100 printers in the system? Note that I said
spool to, and not print to. If your users are on dumb terminals or
terminal servers, I can see why this OSR5 box needs to spool print jobs
for each of them. However, if they are Windoze boxes, or Unix
workstations they can spool their own jobs and talk to the printers
directly. Unless you're doing some post-processing with filters, I don't
see the need for 100 print spoolers. If some of these lpd printers are
really parallel printers attached to workstations, the spooling could
become really entertaining.
See:
http://www.utexas.edu/academic/otl/software/lpr/
for a Windoze lpr client.
2. By using a server as an lpr/lpd print spooler, do you realize that
each job goes down the network twice? (From client to server, and from
server to printer). This is not much of a problem on a well connected
ethernet lan, but a royal pain if there are remote offices with marginal
connectivity (i.e. dialup). I recently earned my exhorbitant consulting
fee by merely reconfiguring several remote offices to print directly
instead of going over their slow 1B1 ISDN (64Kbit/sec) remote office
connection, and thus averted a proposed bandwidth upgrade.
3. What does this network look like? Are all 100 printers in the same
Class C address block? With 100 printers, I can guess that there are at
least 100 users. If a Windoze user selects a printer, do they really see
100 printers? I have a system with 25 visible printers and it takes
about 2 minutes for a Windoze client to build a browse list (even though
the master browser has an up to date list). My guess is that 100
printers will take about 5-6 minutes to display.
Good luck.
Tom Parsons
| Although I already wrote to Jeff I didn't get this thread until yesterday.
| For the benefit of the room..
<snipped>
| There was a problem with access to the Intel created queues because the
| default install didn't set the correct attributes on the file
| /usr/intl/proprint and some kind gentlemen in a different thread told what
| the problem was. The afforementioned file just needed a chmod 755.
Not 755, that may cause you other problems. The best solution is:
chown bin:lp proprint
chmod 2111 proprint
--tom
Jeff Liebermann
wrote:
>I have to admit I haven't looked into netcat yet as I find it amazing to believe
>companies like HP and Intel haven't already got good solutions to this problem (as
>it appears to be the case) and I have been trying to get this working on that
>assumption. I will take a look at it this afternoon now that I'm a little less
>stressed out :)
Netcat works well. Some day, I'll get inspired to clean up the docs and
perhaps inscribe an install cerimony.
HP has its head in the sand. Twice in the past 4 years or so, I've
gotten in the middle between HP and SCO on the issue of HPNP bugs. Each
time, SCO said it was HP's product and therefore HP's problem. Meanwhile
HP declared it to be SCO's platform, and therefore SCO's problem. By
coincidence, the exact same nonsense was going on between Corel Draw 5
(under Windoze) making a mess when printing to HP printers. Both
companies should elect representatives, lock them in a windowless room,
and instruct them to do battle until ownership and responsibility is
established.
About 6 months ago, I tried an Intel something print server. I had more
problems than I was willing to troubleshoot and elected to exchange it
for one that I knew would work. Until I see an upgrade to the proprint
software, I won't try it again.
Netcat is the Swiss Army knife of lpr programs. It will print to any
random socket number, which solves yet another stupid problem
precipitated by the various print server manufactories. Each one wants
to "own" its very own socket number, thereby turning a generic lpd
device, into a proprietary abomination. If all print servers listened on
port 515, we wouldn't need netcat. Also, to insure that everything
remains safetly in the hands of proprietary software, the internal print
server names, which control formatting are all different. In the
documentation for ACITS LPR for Windoze is a long list of ways different
manufacturers print servers call "TEXT" and "RAW". Yech.
Sorry about not answering your recent emails, but I have a priority stack
and business to deal with first. When answering a question in news turns
into an email exchange, it starts to resemble unpaid consulting. Nobody
in the newsgroup learns anything from the email answers, and I end up
spending more than a reasonable amount of time doing free consulting. If
you had posted your comments to the newsgroup, you would have obtained
larger exposure, more people would have replied, others would have
learned something, and your answers would have been faster.
I realize that you said that you received the articles late. Fine, but
you also said in your original posting that you had a fixed deadline to
get this done. Therefore, I sent you a copy of my posting via email on
the assumption that it would be faster. I made it clear that it was also
posted. Although it's not obvious, sending an email reply to a news
posting is NOT necessarily an invitation to starting a detailed technical
email dialog.
Jeff Liebermann
wrote:
Nightmare topology deleted... I'll see what I can suggest.
>Improved/standardised queue names for easier queue management.
>Printing direct to print servers/workstations instead of to Novell
>servers/Terminal software emulators.
You're doing it all wrong. In effect, you're trying to manage 100
printers, acting as print servers on users workstations, from a central
locations. This is neither trivial nor a easily accomplished. In
addition, it appears that each print job will traverse the your
800Kbits/sec RF link twice. Once from the workstation to the server, and
back again to the printer. This is gross and disgusting.
>All reports are also 'print only' There is no way of keeping your print job or
>viewing it as a file without administrator intervention.
Not so. You can create fake printers that end up as files. Instead of
having the destination be /dev/lp0, have the destination be a file or a
named pipe that ends in a file. You can even pipe the output directly to
"less" or "more" to page through the output.
>So if there is any
>problem with the unix server, your unix account, novell server, your novell
>account, print server, printer, your workstation, terminal emulator, anything..
>the job will have to be re-compiled and printed again from the beginning.. many
>reports are hundreds of pages and there is bulk paper wasted every day.
All the more reason to trap the output. The problem is formatting which
seems to be imbedded in the application. If you cannot output clean
ascii text, then viewing the output will be problematical. You stated
that filters were impossible because the print commands are imbedded in
the application. Fine, the print command eventually ends in a print
spooler with a destination device. Trap the output at the device and be
done with it. It *CAN* be done.
>Anyway back to the topic.. sorry, the stress is killing me! :)
See:
news:alt.tech-support.recovery
Read a few horror stories. Some are far worse than yours. They may not
fix your current problems, but might make you feel better about it.
>1. Users have their own login so that we can tell what is going on in our
>production server.
Be prepared for an exercise in permissions and ownership.
>2. Users can print direct to networked printers AND workstation connected
>printers.
Users should have UNRESTRICTED access to their own printers. You should
be able to crash the Novell, Linux and SCO Unix servers and still be able
to print. I sure hope you have a good reason for building a combination
server based and peer-to-peer printing pretzel because I smell trouble.
I don't know if you saw my comments on using the server to spool to a
print server, but methinks this sucks. You should be printing directly
to the print servers.
>2a. direct from the Unix host to the print servers
See the tech articles I previously posted for 3 port servers. I'm
partial to Netcat. lpr/lpd is 2nd best. HPNP if you're desperate.
>2b. direct from the Unix host to the lpd server NT4 thoughtfully provides (thanks
>anyway for the tip.)
That's easy. Just setup the NT4SP3 (good luck with SP5) server for lpd
printing. That's the way I have my it running in my office.
>see: http://www.ntfaq.com/ntfaq/printing17.html#printing17
Nice instructions.
>3. Users can send their print jobs via email back to themselves instead of
>printing with a file attached of the job that they can then manipulate and view
>on any application.
Nothing to it. I have email aliases for every one of my printers. I can
email a message to any printer. Here's how:
Add something like the following to
/usr/mmdf/table/alias.ali
Run:
/usr/mmdf/dbmbuild
after making any changes to mmdf files.
=================================================
# Part of /usr/mmdf/table/alias.ali
# Dump to printer via email
hp2 "lp| /usr/bin/lp -d hp2"
hp3 "lp| /usr/bin/lp -d hp3"
ticket "lp| /usr/bin/lp -d ticket"
plotter "lp| /usr/bin/lp -d plotter"
=================================================
The space after the pipe symbol is manditory.
Email to h...@machine.whatever.dom will be printed immediately. It's
really handy for upper management types that can't use a computer but
still want to recieve email.
>4. We have the option after all this to have the job saved to the users' home
>account to prevent re-compilation.
Yech. Just send it to the user via email. Let the user figure out what
to do with their own printing mess.
>5. This is also designed to proof the Unix infrastructure against Novell
>problems. Even if Novell dies the production system will work and thus also
>prevent needless downtime for production.
I don't see how it does that. If anything, it entangles the various
operating systems even worse. You've got Linux, SCO Unix, Novell
something, Windoze, and NT4SP5. The only OS missing is QNX and perhaps
MacOS. I've seen such monstroscities before and they are usually the
result of purchasing one OS to fix the problems caused by another. IMHO,
it's better to do battle with what you have, than to add a new OS to the
puzzle.
>Any comments on our configuration are most welcome.. see waffly notes above and
>below.
BLAAAAAAH! Yech, retch, yuck, etc...
>We have 3 class C licences, only 2 are in use and we could use one with
>subnetting if we were being efficient. That is being addressed with the DHCP
>server. Previously/currently all IP addresses were assigned manually and there is
>no documentation on what is where (did I mention I nearly quit 2 weeks after
>arriving?)
I've had a bit of experience dealing with fixed IP to DHCP systems. My
rule is if the customer can't handle a manual system, the automatic
system will be even worse. DHCP still requires some level of
organization and control. If that was not present in the fixed IP
system, it will probably not appear under DHCP. There are lots of
wonderful ways to mess up DHCP.
>The DHCP server means all the new pc's are being allocated from here
>(albury).. we haven't tried the remote sites yet but the Unix guy I normally work
>with assures me it will be fine.
He might be wrong. DHCP broadcasts do not have a destination address
usually don't go through routers. In general, you need one DHCP server
for every router. The alternative is to pass everything down your
800Kbits/sec narrow pipe, which largely defeats the purpose of the
router.
>We don't share any workstation resources or do any of that peer-peer networking
>unless death himself comes and asks us to.
Ahem. I just read that you wanna print to any workstation printer. That
sure sounds like sharing to me.
I don't see why you're implimenting such a centrist model. What you're
really doing is implimenting a single point of failure. If your servers
and communications were reliable, I wouldn't complain, but from your
description, that's the problem you're trying to solve.
>Users only see printers on the
>'network' of which there would be about 25 I guess and yes it takes a few
>minutes.. however the workstations are configured by us and the user never has to
>to anything like that ...
I see. You don't trust or want to educate your users, so you take all
the responsibility upon yourself. When is your next ulcer scheduled?
How can you limit what a user can see on a Class C lan? If you split up
the lan between the two Class C addresses you're using, I can see 50
printers on each network. My *GUESS* is the reason they can only see 25
printers is that your mixed bag of print servers and workstations are
using every protocol from IP, DLC, IPX/SPX, and NETBEUI. I've exerted
considerable effort assembling an all IP network, with no other
protocols. It's not easy, but it can be done. Do it as it's worth the
effort.
>Thanks again for the tips, I haven't got around to netcat yet but will try it as
>soon as I get a chance.
Try it. You'll like it.
Clint Zikesch
went straight to that.. don't know!
Clint Zikesch
For the benefit of the room..
Thanks, oss497c fixed all problems with queues disappearing.
Thanks for the advice about multiple questions I guess I felt they were
related.
Already had the HP print servers working off our DHCP server by using BOOTP.
The queues I created worked on everything except the Netport XL they were
just impossible to tell apart!
The problem with using different methods of formatting is that the commands
are coded into our production program and although over the weekend I found
the scripts i'm reluctant to edit them as there is about 1 million lines of
code and I have no idea what else might be affected.
Filters would not fix the problem either as the difficulty is that in a 3
port print server using the method I was trying required the rp setting to be
a text string which was interpretted to direct output to the correct port as
that string then became the queue name which meant they were impossible to
differentiate :(
I have since installed the intel configuration program which got all the
Intel print servers working fine. The HP internal single port print servers
haven't got a problem except an old model which doesn't even have any IP
configuration section. The HP configuration tool on SCO doesn't appear to be
able to configure for different ports so the HP 3 port server is going to be
configured as I described in my first message (luckily we only have one!)
There was a problem with access to the Intel created queues because the
default install didn't set the correct attributes on the file
/usr/intl/proprint and some kind gentlemen in a different thread told what
the problem was. The afforementioned file just needed a chmod 755.
Thanks again and as I will be finalising tests of the config today I will
post the results in case anyone else is interested in the final config.
Regards
Clint
Jeff Liebermann wrote:
> On Wed, 06 Oct 1999 19:09:33 +1000, Clint Zikesch <czik...@mtgl.com.au>
> wrote:
>
> >First question:
> >It doesn't seem likely that when I add a new printer using scoadmin
> >under SCO 5.0.5 it should immediately disappear.. Therefore even though
> >I have added the release supplements I assume there is more to be done.
> >Can someone point me in the right direction on this? (I am using rlpconf
> >for the time being and finding it quite adequate)
>
> Yawn. OSS497B fixes this problem. OSS497A doesn't.
> Also see:
> My network printers configured with lpd are missing
> in Printer Manager.
> http://www.sco.com/cgi-bin/ssl_reference?109737
> for the fast fix.
>
> >Second question:
>
> Please don't mix more than one question per posting. It tends to create
> confusion.
>
> >I have successfully used my DHCP server to assign addresses to most of
> >the print servers.. some refused their IP addresses and are assigned
Clint Zikesch
Tom Parsons wrote:
> This is not a programming questions, reply only to comp.unix.sco.misc.
Ok thanks. :)
>
> Are you sure you want to suffer this torture? :-) Before you go much
> further, look at netcat. http://www.cruzio.com/~jeffl/sco/lp/
I have to admit I haven't looked into netcat yet as I find it amazing to believe
companies like HP and Intel haven't already got good solutions to this problem (as
it appears to be the case) and I have been trying to get this working on that
assumption. I will take a look at it this afternoon now that I'm a little less
stressed out :)
> It is configurable, easy to use, makes your printers act and look like
> local spooler printers plus can be used to eliminate the annoying form feed
> that some Intel print servers force upon you.
Regards
Clint
Clint Zikesch
> On Thu, 07 Oct 1999 20:03:03 +1000, Clint Zikesch <czik...@mtgl.com.au>
> wrote:
>
> Sorry. No clue on the Intel proprint. Nothing useful on their web site.
> I can't tell if you saw my previous reply to your question.
Yes I have posted a query in their newsgroup and still waiting for a reply.. I
will let you know if I find out.
>
> However, I do have some dumb questions that revolve around whatever you
> are attempting to accomplish.
Questions are never dumb.. it's all a matter of perspective :)
Besides with all the dumb questions I've been asking who am I to talk! ;)
>
> 1. Do you really have 100 different print servers that this OSR5 box
> needs to spool to or merely 100 printers in the system? Note that I said
> spool to, and not print to. If your users are on dumb terminals or
> terminal servers, I can see why this OSR5 box needs to spool print jobs
> for each of them. However, if they are Windoze boxes, or Unix
> workstations they can spool their own jobs and talk to the printers
> directly. Unless you're doing some post-processing with filters, I don't
> see the need for 100 print spoolers. If some of these lpd printers are
> really parallel printers attached to workstations, the spooling could
> become really entertaining.
I'll give you the whole rundown - skip down if this is of no interest.
Ok.. we have.. let me check.. 109 printers in total.
We have about 120/130 pc's.. mixed Win3.11/95b/NT4sp4&5/98
We have 2 linux RH6 servers, 3 SCO servers moving to 5.0.5c (my questions are
part of the changeover process). 5 Novell servers 3.12/4.11
There are 4 of us.. The manager.. who is still getting his degree and was given
his job after everyone else in the department quit en masse. An Italian
programmer who maintains our production program (thank God as there is no
documentation and all the internal notes are Italian). A helpdesk operator who
is also still getting her degree and in her first 3 months of this work.
Myself.. 5 years experience with Novell, workstation setup/rollout, staff
managment, helpdesk operations, perl programming, database design/building,
policy/procedure design etc..(I have low self-esteem.. this is to remind myself I
am here for a reason)
We operate over 4 sites. Main site here in Albury which is roughly between our
Sales offices in Melbourne and Sydney which are connected via Frame Relay
(64Kb). The other site is the Managing Directors house which is connected via
Radio Frequency Network (800Kb theoretically).
The setup we have now is that the production program runs here in our Albury
office accessed via Terminal software from Windows based computers in all sites.
Printing services to workstation printers is taken care of by the terminal
software. Printing to print server based printers is accomplished by setting up
remote novell queues on the main SCO server.
Although this works there are a few problems. The users in the production
program login as a single username. By the time the job reaches a novell queue
it is unidentifiable within a reasonable timeframe. If the connection to the
novell server is broken or the novell server dies then all printing dies (of
course). The novell server is also acting as the router for the sales offices
with similiar problems.
The problem with the novell server was that it crashed.. more or less constantly
because of poor maintenance/admin/config and the crappiest software money could
not buy (because they would only buy the cheapest/worst software that you've
never heard of). This on top of nil security or file management and a really bad
network cabling layout.
So... I am now in charge of Y2K, WAN, Unix Servers. I have 4 days to get the
Unix servers re-configured as follows.
New Compaq servers running SCO 5.0.5 connected to a raid array with a backup
server.
Individual logins for users.
Improved/standardised queue names for easier queue management.
Printing direct to print servers/workstations instead of to Novell
servers/Terminal software emulators.
All reports are also 'print only' There is no way of keeping your print job or
viewing it as a file without administrator intervention. So if there is any
problem with the unix server, your unix account, novell server, your novell
account, print server, printer, your workstation, terminal emulator, anything..
the job will have to be re-compiled and printed again from the beginning.. many
reports are hundreds of pages and there is bulk paper wasted every day.
I have to make a comment at this point.. the guys to setup this system spent
millions of dollars.. at least 4 million. The administration mistakes (i'm being
kind) they made were all things I learnt about at University as fundamental data
centre operating procedures. This never had to be this way. Now we have a huge
mess compounded by the year 2000 to fix.
Anyway back to the topic.. sorry, the stress is killing me! :)
So I am trying to set things up so that..
1. Users have their own login so that we can tell what is going on in our
production server.
2. Users can print direct to networked printers AND workstation connected
printers.
2a. direct from the Unix host to the print servers
2b. direct from the Unix host to the lpd server NT4 thoughtfully provides (thanks
anyway for the tip.) we are moving all pc's to NT4sp5 and although our Terminal
sofware - TTWin - allows you to print to a local port it's very expensive (~$5000
for 100 user license if I remember correctly) When we could be using a cheap
emulator and the free lpd server!
see: http://www.ntfaq.com/ntfaq/printing17.html#printing17
3. Users can send their print jobs via email back to themselves instead of
printing with a file attached of the job that they can then manipulate and view
on any application.
4. We have the option after all this to have the job saved to the users' home
account to prevent re-compilation.
5. This is also designed to proof the Unix infrastructure against Novell
problems. Even if Novell dies the production system will work and thus also
prevent needless downtime for production.
>
> See:
> http://www.utexas.edu/academic/otl/software/lpr/
> for a Windoze lpr client.
>
> 2. By using a server as an lpr/lpd print spooler, do you realize that
> each job goes down the network twice? (From client to server, and from
> server to printer). This is not much of a problem on a well connected
> ethernet lan, but a royal pain if there are remote offices with marginal
> connectivity (i.e. dialup). I recently earned my exhorbitant consulting
> fee by merely reconfiguring several remote offices to print directly
> instead of going over their slow 1B1 ISDN (64Kbit/sec) remote office
> connection, and thus averted a proposed bandwidth upgrade.
>
Any comments on our configuration are most welcome.. see waffly notes above and
below.
>
> 3. What does this network look like? Are all 100 printers in the same
> Class C address block? With 100 printers, I can guess that there are at
> least 100 users. If a Windoze user selects a printer, do they really see
> 100 printers? I have a system with 25 visible printers and it takes
> about 2 minutes for a Windoze client to build a browse list (even though
> the master browser has an up to date list). My guess is that 100
> printers will take about 5-6 minutes to display.
>
We have 3 class C licences, only 2 are in use and we could use one with
subnetting if we were being efficient. That is being addressed with the DHCP
server. Previously/currently all IP addresses were assigned manually and there is
no documentation on what is where (did I mention I nearly quit 2 weeks after
arriving?) The DHCP server means all the new pc's are being allocated from here
(albury).. we haven't tried the remote sites yet but the Unix guy I normally work
with assures me it will be fine.
We don't share any workstation resources or do any of that peer-peer networking
unless death himself comes and asks us to. Users only see printers on the
'network' of which there would be about 25 I guess and yes it takes a few
minutes.. however the workstations are configured by us and the user never has to
to anything like that (they have enough trouble getting logins correct.. The
question - your password is about to expire would you like to change it
invariably elicits the response - NO.)
I hope this is not too much jabber.. it's good to get someone else's opinion from
time to time right? Anyway I hope the information provided was of interest.. any
questions please feel free to ask.
Thanks again for the tips, I haven't got around to netcat yet but will try it as
soon as I get a chance.
Regards
Clint
(remove the space)
czikesch@ mtgl.com.au
To have no errors
would be life without meaning.
No struggle, no joy.
Clint Zikesch
> Netcat works well. Some day, I'll get inspired to clean up the docs and
> perhaps inscribe an install cerimony.
>
> HP has its head in the sand. Twice in the past 4 years or so, I've
> gotten in the middle between HP and SCO on the issue of HPNP bugs. Each
> time, SCO said it was HP's product and therefore HP's problem. Meanwhile
> HP declared it to be SCO's platform, and therefore SCO's problem. By
> coincidence, the exact same nonsense was going on between Corel Draw 5
> (under Windoze) making a mess when printing to HP printers. Both
> companies should elect representatives, lock them in a windowless room,
> and instruct them to do battle until ownership and responsibility is
> established.
>
Yes I've just re-read all I can find on the HP stuff and it's pretty useless. I prefer
HP print servers simply for the 3 'real' parallel ports instead of the Intel 2 ports
and one nuisance print server. the 'Intelligent' 3P100 we have is another true 3 port
but has the same difficulty with port naming - however it has one advantage.. it's
cheap!
>
> About 6 months ago, I tried an Intel something print server. I had more
> problems than I was willing to troubleshoot and elected to exchange it
> for one that I knew would work. Until I see an upgrade to the proprint
> software, I won't try it again.
Proprint seems to be working fine but it's quite unclear how the queues work.
>
> Netcat is the Swiss Army knife of lpr programs. It will print to any
> random socket number, which solves yet another stupid problem
> precipitated by the various print server manufactories. Each one wants
> to "own" its very own socket number, thereby turning a generic lpd
> device, into a proprietary abomination. If all print servers listened on
> port 515, we wouldn't need netcat. Also, to insure that everything
> remains safetly in the hands of proprietary software, the internal print
> server names, which control formatting are all different. In the
> documentation for ACITS LPR for Windoze is a long list of ways different
> manufacturers print servers call "TEXT" and "RAW". Yech.
>
> Sorry about not answering your recent emails, but I have a priority stack
> and business to deal with first. When answering a question in news turns
> into an email exchange, it starts to resemble unpaid consulting. Nobody
> in the newsgroup learns anything from the email answers, and I end up
> spending more than a reasonable amount of time doing free consulting. If
> you had posted your comments to the newsgroup, you would have obtained
> larger exposure, more people would have replied, others would have
> learned something, and your answers would have been faster.
Thanks and your help has been much appreciated Jeff.. I wasn't expecting more than a
few pointers and the pointers you gave have helped me sort the problem out.. I do tend
to write expansively when stressed so I apologise if this has been too much. I did
write a rundown to the room for the benefit of all - you may not have seen it yet.
>
> I realize that you said that you received the articles late. Fine, but
> you also said in your original posting that you had a fixed deadline to
> get this done. Therefore, I sent you a copy of my posting via email on
> the assumption that it would be faster. I made it clear that it was also
> posted. Although it's not obvious, sending an email reply to a news
> posting is NOT necessarily an invitation to starting a detailed technical
> email dialog.
>
Again thankyou and I apologise for any inconvenience. I have just figured out the
problem was that one of my ISP's (the cheaper one) hasn't updated it's news and your
message is still not there. I only emailed on the assumption you had only emailed me.
Rather than submit the lengthy reply I made to the room in case it would make no
sense. Apologies again.
I have already mentioned it but I will post my final config for the benefit of everyone
and I hope that makes up for the mixup.
Regards
Clint
Network Administrator
Macquarie Textiles Group
Albury NSW
Australia
czik...@mtgl.com.au
Clint Zikesch
> On Mon, 11 Oct 1999 11:09:24 +1000, Clint Zikesch <czik...@mtgl.com.au>
> wrote:
>
> Nightmare topology deleted... I'll see what I can suggest.
>
I think I may not have clearly stated what I meant.. let's see..
>
> >Improved/standardised queue names for easier queue management.
> >Printing direct to print servers/workstations instead of to Novell
> >servers/Terminal software emulators.
>
> You're doing it all wrong. In effect, you're trying to manage 100
> printers, acting as print servers on users workstations, from a central
> locations. This is neither trivial nor a easily accomplished. In
> addition, it appears that each print job will traverse the your
> 800Kbits/sec RF link twice. Once from the workstation to the server, and
> back again to the printer. This is gross and disgusting.
No.. I am trying to enable printing direct to print servers from the unix box INSTEAD
of via the Novell server queues. This will simplify printing.. If you've seen Netware
4.11 you would agree.
The processing for these jobs does not occur on the workstation.. it's at the server
end.. so the server generates the job.. sends it to the print server which is in some
cases a workstation.. and from there to the printer.. which is in those cases local.
Did I mention the 800Kb RF link is just the MD.. he has one pc only.. I wish we had
that bandwidth to the sales offices! They are the next problem with only 64Kb links
and we use tie-lines there as well.
It would be gross and disgusting if it were as you describe.. I must not have made
myself clear.
> >All reports are also 'print only' There is no way of keeping your print job or
> >viewing it as a file without administrator intervention.
>
Again I apologise.. they are 'print only' NOW.. I already have a method of
email-back-to-me implemented within the production program ready for rollout but it
cannot be used until users are identifiable of course.
> Not so. You can create fake printers that end up as files. Instead of
> having the destination be /dev/lp0, have the destination be a file or a
> named pipe that ends in a file. You can even pipe the output directly to
> "less" or "more" to page through the output.
>
Thanks yes that has been examined but as you note below the users are not trained and
to give them another platform to learn is unthinkable. This is a factory environment
where control is critical - we don't want people wasting their time fiddling with
their pc.
>
> >So if there is any
> >problem with the unix server, your unix account, novell server, your novell
> >account, print server, printer, your workstation, terminal emulator, anything..
> >the job will have to be re-compiled and printed again from the beginning.. many
> >reports are hundreds of pages and there is bulk paper wasted every day.
>
> All the more reason to trap the output. The problem is formatting which
> seems to be imbedded in the application. If you cannot output clean
> ascii text, then viewing the output will be problematical. You stated
> that filters were impossible because the print commands are imbedded in
> the application. Fine, the print command eventually ends in a print
> spooler with a destination device. Trap the output at the device and be
> done with it. It *CAN* be done.
>
Thanks yes I know and that is what I am implementing.. it's the 'how' part that's a
plague because of the convoluted history of the setup. I do hope I'm not contributing
to that convolution but something must be done. It took me several days of needling
to convince the Italian programmer visiting us from Italy that this is what we want
(exactly what you said) and that it could be done.
>
> >Anyway back to the topic.. sorry, the stress is killing me! :)
>
> See:
> news:alt.tech-support.recovery
> Read a few horror stories. Some are far worse than yours. They may not
> fix your current problems, but might make you feel better about it.
>
>
Thanks :)
> >1. Users have their own login so that we can tell what is going on in our
> >production server.
>
> Be prepared for an exercise in permissions and ownership.
>
Yes already getting into that..
>
> >2. Users can print direct to networked printers AND workstation connected
> >printers.
>
> Users should have UNRESTRICTED access to their own printers. You should
> be able to crash the Novell, Linux and SCO Unix servers and still be able
> to print. I sure hope you have a good reason for building a combination
> server based and peer-to-peer printing pretzel because I smell trouble.
> I don't know if you saw my comments on using the server to spool to a
> print server, but methinks this sucks. You should be printing directly
> to the print servers.
>
The workstations can of course use their own printers.. they just don't advertise them
as shared.
The lpd server of NT will mean they are effectively print servers yes.. but for the
attached printer of the workstation and only for our production system. This will
mean anyone can print to any of these printers from our production program. Currently
this cannot be done - it's not strictly necessary and isn't planned to be implemented
until a later date. I am only dealing with the Networked printers we currently have
at the moment.. about 25 as mentioned.
However if we can print to all printers it will reduce the need to buy more print
servers. I am hoping to cut down on the number of printers we have.. there are far
too many.
Users DO have unrestricted access to their own printers. All servers down and yes you
can print to your own printer.. however the point of networking is to share. and
without servers there is nothing worth printing.
The reason for different services in brief..
SCO - production platform for stability and centralised production program. This is
where the factory work is done - 1 big app only & printing, mission critical.
Novell - everyday office work, spreadsheets, ad-hoc databases, word docs, and about
100 different apps for everything from greeting cards/posters to maintenance
programs/diagramming tools... try getting even half this stuff on Unix for a
reasonable price. As a result requiring alot of maintenance and inevitably having
problems requiring server restart periodically.
Linux - cheap, reliable, providing services as DHCP server, DNS server and Mail
server. and when we have problems with any of these services we can actually restart
the server without bothering anybody.. the 2nd server is a backup to the primary..
being cheap this was no problem.
At the moment if Novell dies we lose SCO with it and all production. I am trying to
prevent that. To get all this working on one platform I think would be very
difficult. There are ways to do it I know but inevitably there are problems with any
config. As I have stated I didn't make this mess I'm just trying to clean up a
little.
My preference would be to have the mission critical app rebuilt into an SQL server
based program that we can deliver better to a pc.. that way it's more portable but
currently we are locked into this state. The separation of services means that
problems do not bring down everything.. it is currently a pretzel but I'm trying to
cut it up a little more neatly so that it's easier to swallow. It appears from your
comments I made it sound like the current config is what I am proposing.. sorry for
the confusion.
>
> >2a. direct from the Unix host to the print servers
>
> See the tech articles I previously posted for 3 port servers. I'm
> partial to Netcat. lpr/lpd is 2nd best. HPNP if you're desperate.
>
> >2b. direct from the Unix host to the lpd server NT4 thoughtfully provides (thanks
> >anyway for the tip.)
>
> That's easy. Just setup the NT4SP3 (good luck with SP5) server for lpd
> printing. That's the way I have my it running in my office.
> >see: http://www.ntfaq.com/ntfaq/printing17.html#printing17
> Nice instructions.
>
Have already done it with sp5 on my pc.. also easy :)
>
> >3. Users can send their print jobs via email back to themselves instead of
> >printing with a file attached of the job that they can then manipulate and view
> >on any application.
>
>
> Nothing to it. I have email aliases for every one of my printers. I can
> email a message to any printer. Here's how:
> Add something like the following to
> /usr/mmdf/table/alias.ali
> Run:
> /usr/mmdf/dbmbuild
> after making any changes to mmdf files.
> =================================================
> # Part of /usr/mmdf/table/alias.ali
> # Dump to printer via email
> hp2 "lp| /usr/bin/lp -d hp2"
> hp3 "lp| /usr/bin/lp -d hp3"
> ticket "lp| /usr/bin/lp -d ticket"
> plotter "lp| /usr/bin/lp -d plotter"
> =================================================
>
> The space after the pipe symbol is manditory.
>
> Email to h...@machine.whatever.dom will be printed immediately. It's
> really handy for upper management types that can't use a computer but
> still want to recieve email.
>
Excellent thanks! As I mention above I managed to get the original programmer to add
this kind of thing to the production program but it's not as good as this.. I will try
to do something with it.. however - we use sendmail. :(
>
> >4. We have the option after all this to have the job saved to the users' home
> >account to prevent re-compilation.
>
> Yech. Just send it to the user via email. Let the user figure out what
> to do with their own printing mess.
>
Agreed - it's an available option though, I was thinking of giving the user access to
their home dir via NFS.. but it's messy.
>
> >5. This is also designed to proof the Unix infrastructure against Novell
> >problems. Even if Novell dies the production system will work and thus also
> >prevent needless downtime for production.
>
> I don't see how it does that. If anything, it entangles the various
> operating systems even worse. You've got Linux, SCO Unix, Novell
> something, Windoze, and NT4SP5. The only OS missing is QNX and perhaps
> MacOS. I've seen such monstroscities before and they are usually the
> result of purchasing one OS to fix the problems caused by another. IMHO,
> it's better to do battle with what you have, than to add a new OS to the
> puzzle.
>
Well my last job was with a University and I have worked with more platforms including
MacOS all on one network.. it's all in the admin! ;)
The proof is that one server down does not kill the services of the other.. that's
all.
1.workstations alone can still work and print..
2.novell and workstation can share files, print to network printers and run shared
apps
3.sco and workstation can run production program, print to network printers and print
to workstation printers
4.linux provides internet access and ip addresses.. I could do this from novell or sco
but if there are problems and the server has to go down then I have to wait for a good
time.. explain why the server has to go down.. tell everyone.. bring it down.. hope it
works now.. go through the whole thing again if it didn't and worry about how it is
affecting other operations of that server.. I'd rather flick the switch on the linux
box and not worry so much.
My previous employer is going totally NT server with MS Exchange.. they use citrix to
deliver NT I believe.. they are happy with it.. but when we were examining going to
citrix we found that it would cost the same as the novell setup and you would lose the
backstop of having a workstation that works in an emergency. 6 of one, half a dozen
of the other. A setup like ours is difficult because it's not big enough to justify
spending huge sums and not small enough to cut corners. We need to give the users
'restricted flexibility'. To give free reign was how it used to be and we never got
off the phone to do any work. Now we have time to actually figure a few things out.
Centralised is good IMHO, SOE is good, fewer operating systems are good..
unfortunately not every app works on every OS. In this industry alot of apps are
highly specialised and not very robust. We were forced to implement a small peer-peer
for one app to share data between 3 workstations for one app and then log it's server
into our network to share data with another app from the same company. It's a
nightmare.
>
> >Any comments on our configuration are most welcome.. see waffly notes above and
> >below.
>
> BLAAAAAAH! Yech, retch, yuck, etc...
>
LMAO :)
>
> >We have 3 class C licences, only 2 are in use and we could use one with
> >subnetting if we were being efficient. That is being addressed with the DHCP
> >server. Previously/currently all IP addresses were assigned manually and there is
> >no documentation on what is where (did I mention I nearly quit 2 weeks after
> >arriving?)
>
> I've had a bit of experience dealing with fixed IP to DHCP systems. My
> rule is if the customer can't handle a manual system, the automatic
> system will be even worse. DHCP still requires some level of
> organization and control. If that was not present in the fixed IP
> system, it will probably not appear under DHCP. There are lots of
> wonderful ways to mess up DHCP.
>
well I'm controlling it (nobody was before) and I'm using fixed addresses with loong
leases.. the only part that concerns me is the remote ends for the reasons you
mention. however as there are only about 15 pc's on these ends we can always do them
manually in a pinch.
>
> >The DHCP server means all the new pc's are being allocated from here
> >(albury).. we haven't tried the remote sites yet but the Unix guy I normally work
> >with assures me it will be fine.
>
> He might be wrong. DHCP broadcasts do not have a destination address
> usually don't go through routers. In general, you need one DHCP server
> for every router. The alternative is to pass everything down your
> 800Kbits/sec narrow pipe, which largely defeats the purpose of the
> router.
>
hmm thanks for the warning I am concerned about it. I wish we had 800Kb/s to these
links.. they are only 64Kb/s agreggating to here at 128Kb/s and we have a couple of
tie-lines which cuts it back to roughly 32Kb/s :(
>
> >We don't share any workstation resources or do any of that peer-peer networking
> >unless death himself comes and asks us to.
>
> Ahem. I just read that you wanna print to any workstation printer. That
> sure sounds like sharing to me.
>
welll..... only for lpd.. no NETBOOHOOI
I just want to print from the production program to a workstation printer using the NT
lpd service. Workstations do NOT share resources and we don't run NW print server
software on the workstations either (it works but is a pain & performs poorly).
>
> I don't see why you're implimenting such a centrist model. What you're
> really doing is implimenting a single point of failure. If your servers
> and communications were reliable, I wouldn't complain, but from your
> description, that's the problem you're trying to solve.
>
Noted but now we just have multiple points of failure that kill everything anyway!
what does anyone do when a server dies? how many networks are run with everybodys'
files stuck on their own workstation.. then the workstation dies.. print to someones'
printer on another workstation.. but that person is gone today and the workstation is
off and their door locked.. how many times have I spent a day trying to re-create
someone's bizarre desktop configuration because their machine crashed (we are talking
about Microsoft remember!). Go centralisation I say, I have worked support and
believe me trying to fix one server is preferable to 100 workstations.
We have a couple of disk image files that get downloaded to a pc when it dies and we
have a working pc within half an hour. Nobody loses any work because it's all on the
server and backed up daily. We can share what we want, run what we want where we want
it. We can remote control the pc to avoid treking over the 1 Km/sq of factory and
driving 3 hours to Melbourne or 6 hours to Sydney. The only real question was whether
or not to go with a citrix type implementation instead of pc. The only alternative to
Novell in a mid-range environment is NT server and I'm willing to go out on a limb and
call NT less than stable with more bugs than Novell - fact or fiction?
We could deliver apps with Samba or whatever SCO offers as an equivalent but out here
there aren't alot of Unix experts and less who know anything about workstation
support.
>
> >Users only see printers on the
> >'network' of which there would be about 25 I guess and yes it takes a few
> >minutes.. however the workstations are configured by us and the user never has to
> >to anything like that ...
>
> I see. You don't trust or want to educate your users, so you take all
> the responsibility upon yourself. When is your next ulcer scheduled?
>
Ulcer? we're talking full blown coronary! :)
I'd rather spend a few minutes actually doing it than half an hour explaining it
(multiplied by 450 people over 3 shifts - we are 24hr's on!)
Seriously though.. we are in a factory.. I don't know how many factory workers you
know but I came from my last job with a very enlightened attitude about user
training. After telling one person 5 times how to login using their password. Another
user needed to know where the colon key was.. when I pick up another guys' phone here
in the office and say 'Clint speaking' for a long time people would say '..oh Tom I
have a problem...'.
People need training to do their job properly.. but these people mostly use the
computer to record what is happening on the floor.. we try to make it simple for
them. They don't know how to configure a printer icon. It took 6 months to convince
them they needed to use their own login instead of sharing passwords. One department
had themselves sent on an Access Database course and started writing databases to
replace the production program.. very BAD databases!
>
> How can you limit what a user can see on a Class C lan? If you split up
> the lan between the two Class C addresses you're using, I can see 50
> printers on each network. My *GUESS* is the reason they can only see 25
> printers is that your mixed bag of print servers and workstations are
> using every protocol from IP, DLC, IPX/SPX, and NETBEUI. I've exerted
> considerable effort assembling an all IP network, with no other
> protocols. It's not easy, but it can be done. Do it as it's worth the
> effort.
>
No again.. we use IPX 803.2 and IP. NETBEUI was forced upon us for 3 pc's.
Everything is visible to everyone. The mill site is on one C and the WAN sites on
another. We have a gateway server and everything works fine. There are only 25
printers on network devices advertising services. Agreed about one protocol.. when we
get to Novell 5 we will be able to do that.
>
> >Thanks again for the tips, I haven't got around to netcat yet but will try it as
> >soon as I get a chance.
>
> Try it. You'll like it.
>
I'll let you know :)
Ok.. well I hope that is a little more clear but again - very glad of comments,
complaints and concerns. Thanks for the tips and info. I never take tech info
personally and am happy to be told when I am wrong.. how else can I improve. :)
Regards
Clint
czikesch@ mtgl.com.au
Having been erased,
the document you're seeking
must now be retyped.
Tony Lawrence
: Not 755, that may cause you other problems. The best solution is:
: chown bin:lp proprint
: chmod 2111 proprint
I doubt it would cause anyproblems. The program gets called by lp, not
by the user, so the process already has the permissions it needs for lp files.
--
Tony Lawrence (to...@aplawrence.com)
SCO Articles, Tips, Book Reviews: http://www.aplawrence.com
Clint Zikesch
> Sorry. No clue on the Intel proprint. Nothing useful on their web site.
> I can't tell if you saw my previous reply to your question.
>
I have a response from the Intel thread.. nobody knows!
<intel response>
I wish I had more information on this. I do know that managing the print
servers is not really an option using anything other than what we provide
via either the NetportŽ Manager software or the web interface of the print
server itself. As far as documentation for setting this up with SCO* I have
been frustrated in the past myself on this one. I am pushing for something
to be done on this so we can get more information out to the customers.
I understand that some of the instructions no longer work with the latest
version of SCO (the latest we have tested with is 5.04), but I do know that
some sort of core OS patch is required to make the whole thing work - you
should contact the system vendor for this.
<ends here>
However I am one up on Intel today as I can print to their old XL model using one
ip address.. which I am told is impossible! I'll just go read my impossible
printouts again! hehe ;)
XL was upgraded to rev 3.25a, DHCP assigned IP address.. nothing in the lpr tab..
setup using proinstall the same as any intel print server.. works fine. The
support guy was rather surprised. Will let you know if it turns out to be
interesting.
Regards
Clint
Jeff Liebermann
wrote:
>However I am one up on Intel today as I can print to their old XL model using one
>ip address.. which I am told is impossible! I'll just go read my impossible
>printouts again! hehe ;)
Perhaps it would help if I explained *HOW* multi-port print servers work.
IP addresses are assigned to interfaces. An interface is a cute name for
an ethernet port (or a serial port running PPP). IP addresses are NOT
assigned to devices (printers, computers, servers, routers, etc), only
interfaces. An interface can be multi-homed and have more than one IP
address, but this is normally not done for print server port selection.
One way print servers select multiple printers is to look for data on
multiple ports. I don't wanna try and find the Intel docs, but HP EX3
listends on ports 9100, 9101 and 9102, for printer ports 1,2, and 3
respectively. By definition, these ports are all "raw" and do no
formatting. This is ilustrated in:
http://www.sco.com/cgi-bin/ssl_reference?105327
The port numbers change with each manufactory.
Another way is "virtual" printers or port names. The print server
accepts data on a single IP port (usually 515), and selects the virtual
printer by name. For HP EX3, this TEXT1, TEXT2 and TEXT3 respectively.
See:
http://www.sco.com/cgi-bin/ssl_reference?104997
The names can be changed to confuse the innocent. RAW1, RAW2, and RAW3
are the names used for Postscribble printing. There are other names.
The virtual printer names also change with manufactory. If you expect to
have the print server do some formatting (IMHO a bad idea) then the exact
name determines the level of formatting. Dragged to its extreme, the
Axis 540 print server includes a postscript stripper and an EBCDIC to
ASCII converter. Usually, the port name is just used for CR-LF
translation.
I have no clue (and little interest) in discovering which ports and
virtual printer names that Intel uses. I did find a list on the web with
a table of known port numbers and names. Now, I can't find it. Argh.
However, the mechanisms for port selection, by IP port number and by
virtual printer name, should be identical for all print servers.
Drivel: I found this note in the ACITS lpr print client docs.
Some HP JetDirect devices may not be compatible with LPD printing
(RFC 1179). The device may need to be updated to a newer version.
Also, JetDirect devices using firmware revision 03.15 through 04.08
are known to have problems with control files of certain sizes
(approximately 99 bytes). HP recommends upgrading the firmware
to 04.09 or later.
Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote:
>I have no clue (and little interest) in discovering which ports and
>virtual printer names that Intel uses.
Intel prints on ports 3001, 3002 and 2501 for parallel 1, parallel 2, and
serial 1 respectively.
Clint Zikesch
> >However I am one up on Intel today as I can print to their old XL model using one
> >ip address.. which I am told is impossible! I'll just go read my impossible
> >printouts again! hehe ;)
>
> Perhaps it would help if I explained *HOW* multi-port print servers work.
>
Well I only meant that the tech support expressed great surprise that I didn't have to
set an ip address for each interface. Subsequent models use one IP/multi port. Not
this model which requires separate IP interfaces. However thanks I didn't know that
much about *how* it actually worked apart from a vague notion. :)
The only other oddity is that this XL was made in Puerto Rico! hmmmm..
Yeah I know what you mean about the ports page.. I saw it.. noted it.. lost it! But I
have the port numbers already thanks. You may be interested in this page.. the
Technical Description.
http://support.intel.com/support/netport/vintage/6114.htm
There is a support forum on newsgroups.intel.com
intel.networking_and_communications.network_print_products
where I have had some further information.. may be valuable to anyone trying to get
these things working.
I just read your notes on netcat.. it seems like the only way to go for a uniform way
of managing these things. Thanks for all your help Jeff :)
Regards
Clint
Clint Zikesch
> rule is if the customer can't handle a manual system, the automatic
> system will be even worse. DHCP still requires some level of
> organization and control. If that was not present in the fixed IP
> system, it will probably not appear under DHCP. There are lots of
> wonderful ways to mess up DHCP.
Jeff I must bow before your wisdom yet again!! :(
Although I thought I had this thing under control the best way to mess it up it seems
is to have a manager who thinks he knows what he's doing! It's very simple for me.. I
check nothing has the address (physically went to each pc and got it), check it again
by a trial ping.. assign it.. no problem.
However other people for some reason think using a logic beyond my comprehension.
Scenario 1. Assigned ip address.. it works.. network card swapped with another by
mgr.. hey Clint how come this thing doesn't work anymore? Your DHCP server must be
wrong - I have already rebooted it but it doesn't make any difference!
Scenario 2. Mgr wants ip address of new pc set to match address of old pc for user.. I
ask questions like.. these aren't going to be on at the same time are they cause it
won't work.. answer: no we'll take one off and put the other on.. result.. 2
non-functional pcs' one pissed off user (a dept mgr of course) and another quick
lesson in address assignment.
Scenario 3. I have a list that has 3 columns 1.pc currently assigned to an address.
2.the ip address in question. 3.pc TO BE assigned the addressed when the old pc
leaves. However this seeminly straight forward document suffered a similar fate.. It
was decided to re-assign some addresses to get them out of a range reserved for
servers. ok.. however instead of just changing the current column.. half the current
column gets erased.. the future column is all filled in.. some of those now in the
future are actually current while others who weren't correctly changed are still right
(not that I can tell anymore).. I have no idea what anything in the list is assigned
to or what I originally had down.
awwww sh#$!
I shouldn't have spent years learning technical skills.. I need a Bachelor in BS to
get a managment job.. it's all so clear to me now. :(
Tony Lawrence
> However other people for some reason think using a logic beyond my
> comprehension. Scenario 1. Assigned ip address.. it works.. network card
> swapped with another by mgr.. hey Clint how come this thing doesn't work
> anymore? Your DHCP server must be wrong -
DHCP is one of those things that should be installed only if
you have to use it. It only makes sense in large
organizations where the alternative has a worse bite than it
does. Otherwise, you are so much better off with fixed,
controlled, I-know-where-you-are-and-who-you-are addresses.
Unfortunately, I see more and more of this misapplied
because of Microsoft-their defaults assume DHCP, so the
implication is that this Must Be Good. So, even if the
technical people know better, the clueless middle managers
start to feel left out if they have to have a fixed address,
and they whine, and they fuss, and they throw a lot of
techno-babble at their bosses, and pretty soon IT has to put
in DHCP whether it's indicated or not. I just love it when
technical issues are decided by people apt to spell it
DCHP..
--
Tony Lawrence (to...@aplawrence.com)
SCO articles, help, book reviews, tests,
job listings and more : http://www.aplawrence.com
Clint Zikesch
1) with a DNS server available we would be able to reference things by name..
alot easier for us to remember and alot easier if a machine is changed over -
everything previous was referenced by address and without carrying a book
(which
didn't exist anyway), impossible to remember.
We were using host files but with 9 servers that was getting messy.
There is an unfortunate tendency to move things without telling anyone and that
makes a manual system physically impossible to manage in our environment with
alot of spread and few staff. It got to a stage where it took half an hour to
find a
free address because you couldn't be sure which were in use.
2) the DHCP server would make it easier to tell if hardware was being changed
and once all pc's were on this system alot easier for me to clean up ranges of
addresses. To do this manually would take a week, a couple of flights and a
pair of
good shoes. In other words.. the too hard basket.
I guess the single biggest problem in managing anything I've encountered is
'clear
lines of communication' and 'clearly identifiable roles and responsibilities'.
Alas..
I have never seen these phantoms except as legends in books of managment and
technical lore. :(
Tony Lawrence
>
> Oh well.. the possibly naive idea was that -
> 1) with a DNS server available we would be able to reference things by
> name.. alot easier for us to remember and alot easier if a machine is
> changed over -
i must have missed something here- what's wrong with DNS?
> 2) the DHCP server would make it easier to tell if hardware was being
> changed and once all pc's were on this system alot easier for me to clean
> up ranges of addresses. To do this manually would take a week, a couple
> of flights and pair of good shoes. In other words.. the too hard basket.
Well, maybe you have enough problems that it's worth the
trouble of DHCP?
Everything's a tradeoff, right?
Jeff Liebermann
wrote:
>i must have missed something here- what's wrong with DNS?
My turn. Here's the way I've seen it work at least 3 or 4 times. I'm
going through one of these exercises right now. Note that this is over a
several year period and that the network is growing all the time.
1. Customer starts with an all static IP address system. The official
"keeper of the IP addresses" gets sick, re-assigned, leaves, or otherwise
drops the ball. Address management becomes a mess.
2. The ace consultant impliments DHCP to solve the IP problem. Since
the network is segmented, some organization is required to maintain
sanity. The official "keeper of the DHCP zone tables" gets sick,
re-assigned, leaves, or otherwise drops the ball. DHCP management
becomes a mess.
3. The ace consultant impliments DNS to track the names assigned by
DHCP. In theory, all that's necessary is the MAC address of the
workstation. In reality, there are some services and configurations that
track the Service->Domain->Name->IP->MAC to make portable names work in a
"dynamic" environment. Read about "Portable IP" for details. The
overworked "keeper of the DNS and DHCP server mess" gets sick,
re-assigned, leaves, or otherwise drops the ball. DNS management becomes
a mess.
4. While the DNS+DHCP+IP manager is recovering from overwork, the ace
consultant installs DDNS (dynamic DNS) which allows for on the fly
additions to the DNS tables. This is mostly for workstations and PDA's
that appear and disappear out of nowhere. This either works very well,
or not at all. Not at all is my experience. The DNS+DHCP+IP manager
returns to discover his DNS is configuring itself, and runs screaming
from the office.
5. The ace consultant sells the company on an enterprise management
administration software, build on some directory services mutation, that
promises to organize the entire mess. The 3D view of their company look
cool in the board room. In theory, this can be run by mere mortals, and
does not require waiting for the experienced and competant DNS+DHCP=IP
manager to recover from his neverous breakdown. This allows the new and
instantly overworked NDS or LDAP administrator to enter all kinds of
useless information about the user and machinery which allow the system
to act as inventory control, human resources, maintenance scheduler,
phone directory, and alarm clock. While engaged in dumping the human
resources database into the LDAP or NDS directory, the DNS+DHCP+IP
problems are forgotten and rapidly go out of control.
6. The company hires a network troubleshooter (me) to look at the mess
and try to figure out what additions need to be made. He recommends:
- Tear the whole mess down to basic necessities and get rid of anything
that doesn't generate dollars. Simplify(tm).
- Go back to fixed IP addresses for things that don't move (printers and
server).
- Use DHCP only for dial-in users.
- Toss a coin on workstations, laptops, PDA's depending upon available
human management resources.
- Use DNS for intranet naming only. "What's the name of our company
today" was a question I heard asked last week. Use the machine property
number for a system name. (Thanks for the 8 character limit SCO).
- Hire Mongo, the bouncer, from the local bar, and have him pass out
stickers with IP addresses.
- Anyone caught with a self-assigned IP, duplicate IP, or cloned machine
will be athletically dealt with by Mongo.
This may sound like a joke, but I have exactly this situation, up to step
#5, at one company. We haven't gone to step #6 yet. My drastic
recommendations as to "single application servers" and "decentralized
administration" have been met with resistance by management. The basic
point is that if a company cannot (or will not) expend the resources to
track its own hardware and IP's, then all the software, services, and
acronyms piled on top of the original problem are not going to work any
better.
Note that this is the exact opposite of the thin client (NC) solutions.
The above horror story is about fat clients (Windoze boxes) that are
currently predominant. With a thin client, it makes more sense to use
DHCP and possibly DNS to keep the boxes generic. Since nothing is stored
on the thin client, it must be centrally managed.
Customers calling, gotta run...
Clint Zikesch
experience to hear about some of the problems you have solved. I do
apologise for my self-indulgence in many of my postings.. been a bad
month.
Thanks and Regards
Clint
Bill Vermillion wrote:
> In article <38092310...@dragnet.com.au>,
> Clint Zikesch <czik...@dragnet.com.au> wrote:
> >Bill Vermillion wrote:
>
> >> In article <38066C77...@mtgl.com.au>, Clint Zikesch
> >> <czik...@mtgl.com.au> wrote:
>
> >> >server available we would be able to reference things by name..
>
> ....
>
> >> I you make your hosts file logical that shouldn't be a real
> >> problem. ^<< insert "names"
>
> ...
>
> >But if it's switched off you won't find it. And I can't walk that
> >fast that's it's worth finding out.
>
> That's like printers which throw things away because someone
> thought xon/xoff was easier than wiring for HW flow. Quick and
> easy tends to pile up one large pile.
>
> >I wrote a perl script once to try to physically determine which
> >hub each pc was attached to. These were BNC unmanaged hubs so the
> >idea was to have all machines on.. pull a plug.. run test of every
> >address in a range. repeat for each plug. run a comparison that
> >reveals by absense and matching where ip's are located. It took too
> >long to iron out the bugs so I never quite got it to work right. It
> >was interesting though.
>
> On the little BSD machine I used to monitor the routers and network
> I run 'arpwatch' which notifies me by mail of any machines that
> have changed MAC addresses or are newly added.
>
> >> But users shouldn't be reconfiguring network machines IMO. ...
>
> >No they shouldn't but some believe themselves to be budding
> >hackers. We use fixed addresses so haven't had any problems yet..
> >I'm sure if we were dynamic there would be problems. ...
>
> I have mixed emotions about that. I'd say use the best tool for
> the job in any given environment, and that could be DHCP for some
> and fixed IP for others.
>
> >... Problems are being generated by my department more than from
> >users.
>
> That's not good.
>
> >Yes.. if I can get others in the dept to tell me what they have
> >done. :(
>
> Welcome to the club.
>
> >... what the hell are all these dots in the name for? WAAY too
> >complicated...
>
> (see Tony's comment on the other thread with regards to name and IP
> number)
>
> >... So of course then I have to take all the calls and say..
> >well I have nothing to do with it.. and don't know how it works..
> >better call &&& about it. ...
>
> >I've aged 2 years in the last 6 months. *sigh* Is this normal guys?
> >Am I a lunatic as I sometimes suspect? Worse.. am I wrong? I was
> >planning to quit and take up a ski-instructing job for a while..
> >maybe tomorrow..
>
> Nothing wrong with skiing on a bright warm sunny day with the water
> above 75 degrees :-)
Clint Zikesch
> Most people should not even have to know that level exists, but
> it's important in many areas to use the MAC and also to be able
> to manipulate the address for quick machine changes in fail-over
> systems. The fun will really begin when cheap NIC cards have user
> changeable MACs :-(
>
In my last job we once got a shipment of NIC cards that we discovered
were programmable.. they scared us.. I think we sent them back! :)
>
> It may be my background
> but on a network I really want to know what machines are there and
> where they are. Picky I guess. Old fashioned. Stubborn old fart.
> Pick any (or all) - they'd probably fit.
>
The old ways are usually better thought through. :)
Clint
Clint Zikesch
together and write a book. I'm sure it would do very well. You've got
a lot of common sense solutions to everyday problems at an enterprise
level. There are so many books on technical issues but very few on how
best to setup a managable environment. I am thinking about going back
to Uni with a thesis in this area. Just haven't got enough money
together yet to take the time off.
Kind Regards
Clint
czikesch @ mtgl.com.au
Bill Vermillion wrote:
> >Yes.. if I can get others in the dept to tell me what they have
> >done. :(
>
> Welcome to the club.
>
Where do I pickup my membership card? :)
>
> Nothing wrong with skiing on a bright warm sunny day with the water
> above 75 degrees :-)
I like my water very stiff and vertical :)
CZ
Tony Lawrence
> >The only difference is that you don't have addresses in 8
duh. I meant 4
> >neat little octets- instead they are big, null-terminated
> >strings, requiring much more processing power- but who
> >cares?
>
> But you will have to have a database somewhere to lookup the
> www.aplawrence.com MAC address. And what happens when you change
> NIC cards? A new MAC address with the new card.
No, you wouldn't need a data base to look up the MAC
address, anymore than you do now. You get to the proper LAN
and broadcast "Who belongs to this name?"- same as you do
with IP. You need a data base to look up routing, but
that's no different than the DNS database
> If the IPv6 ever gets approved and implemented, then since everyone
> will have their own IP space with enough IP's below that to access
> every electrically connected device they now own, we can then
> perhaps come to the point of a unversal network address just as a
> few companies are now offering universal phone numbers that move
> with you where-ever you go.
And if it were names rather than ip addresses, it would be
that much easier.
Tony Lawrence
>
> If you don't mind me saying so.. You, Jeff L and Tony really should get
> together and write a book. I
I don't have the patience to write a book. I'd *like* to
write a book, but it's just too much work. That's why I have
a web site instead.
If you took everything I have on my site, plus every post
I've every made here, and stitched it all together, it STILL
wouldn't be half what Jim Mohr did for OSR5 (
http://www.aplawrence.com/Books/companion.html ) or Gene
Henriksen did for Unixware (
http://www.aplawrence.com/Books/uw7sysadm.html )
Writing books is hard, hard work. Maintaining a web site
like mine isn't exactly easy, but it's nothing compared to
writing a whole darn book.
However, if somebody with the necessary skills and patience
wants to HELP us write a book (help as in you do all the
real work), I'd be happy to contribute :-)
Bill Vermillion
Tony Lawrence <to...@aplawrence.com> wrote:
>
>> >The only difference is that you don't have addresses in 8
>duh. I meant 4
>> >neat little octets- instead they are big, null-terminated
>> >strings, requiring much more processing power- but who
>> >cares?
>> But you will have to have a database somewhere to lookup the
>> www.aplawrence.com MAC address. And what happens when you change
>> NIC cards? A new MAC address with the new card.
>No, you wouldn't need a data base to look up the MAC
>address, anymore than you do now. You get to the proper LAN
>and broadcast "Who belongs to this name?"- same as you do
>with IP. You need a data base to look up routing, but
>that's no different than the DNS database
I was thinking along the line of WAN and large LANs. I was also
thinking of routing. On a small LAN a lot is quite superfluous.
You eventually need the MAC to talk to the next machine and I was
thinking of a process to map the name to the MAC. Thus eliminating
the middle step.
>> If the IPv6 ever gets approved and implemented, then since everyone
>> will have their own IP space with enough IP's below that to access
>> every electrically connected device they now own, we can then
>> perhaps come to the point of a unversal network address just as a
>> few companies are now offering universal phone numbers that move
>> with you where-ever you go.
>And if it were names rather than ip addresses, it would be
>that much easier.
There would have to be some formal way of specifiying those.
I can envision something on the order of
continent:nation:region:sub-region:city:name:address:xxxx:yy
So your toaster's slot 4 would be
na:us:ne:mass:boston:aplawrence:123main:toaster:4
:-)
You have to be able to cross-index somewhere, until the systems
become telepathic.
Bill Vermillion
Clint Zikesch <czik...@mtgl.com.au> wrote:
>In my last job we once got a shipment of NIC cards that we discovered
>were programmable.. they scared us.. I think we sent them back! :)
But they are quite useful in certain applications. If you have
mirrored servers, or redundant machines, when the first one goes
off line you give the standby the MAC address that was assoiciated
with the first machine, and life goes on - almost transparently.
Jeff Liebermann
wrote:
>If you don't mind me saying so.. You, Jeff L and Tony really should get
>together and write a book. I'm sure it would do very well. You've got
>a lot of common sense solutions to everyday problems at an enterprise
>level. There are so many books on technical issues but very few on how
>best to setup a managable environment. I am thinking about going back
>to Uni with a thesis in this area. Just haven't got enough money
>together yet to take the time off.
Let's see if I understand this. You want a non-technical book on common
sense enterprise management. Well, that would be a change. I could
think of a few titles:
Tales from the Server Crypt.
Seat of the Pants Systems Design.
Network Topology Over-Simplified.
12 Step Program to Kicking the Microsoft Habit.
Computer Common Sense Solutions without Math.
Forensic Network Analysis.
Learn to RTFM in only 20 days.
Troubleshooting Computers with a Hammer.
Reality and the Bleeding Edge of Technology.
Backups on less than $1 per day.
Convert Your House Electrical Wiring for Ethernet.
100 Easy Ways to Eject a CDROM without Profanity.
Technical Plagerism Made Easy.
What to Do While Waiting for OSR5 to Install.
Do any of these sound like what you want us to write?
Tony Lawrence
> Well, that would be a change. I could
> think of a few titles:
>
> Tales from the Server Crypt.
> Seat of the Pants Systems Design.
...
> What to Do While Waiting for OSR5 to Install.
>
Those are, of course, chapter titles, right?
Tony Lawrence
> Technical Plagerism Made Easy.
I need that one, 'cause I've never found it easy. Every
time I go to plagarize somebody, I find that I really don't
understand the subject, so I have to look into it more
deeply, and then I decide I didn't quite like the way
whoever it was explained it, so I have to write it out my
way anyway. While I'm trying to explain it my way I usually
realize yet again that I'm talking through my hat, so I have
to dig even deeper, and that's why it takes me a long time
to write anything about anything, even when I start out by
-ahem- "borrowing" an idea from someone else.
BTW, Jeff, your newgroup posts are a fertile source of
ideas. In fact, I keep a folder called Ideas where I stick
stuff I'd like to expound upon someday, and your posts
probably outnumber anyone else's. But the problem is
usually as I explained above: I look at one, decide I don't
really know enough about it, so I go search for something
easier :-)
Jeff Liebermann
wrote:
(...)
>to dig even deeper, and that's why it takes me a long time
>to write anything about anything, even when I start out by
>-ahem- "borrowing" an idea from someone else.
Congrats. You're normal. I have to research almost every posting that I
make. In some cases, I can recite my experiences from memory, but the
technical parts require research. Usually, the research takes some time.
If I have to guess my way through a problem, it takes even longer.
That's why I get rather irate at someone that posts a question, but
doesn't bother supplying any useful information (like the OSR5 version
number). I have all my source code, news postings, email, and references
indexed using either Verity or Altavista Personal Search 97. Finding
things by keyword is fairly easy.
>BTW, Jeff, your newgroup posts are a fertile source of
>ideas.
Oh swell. Now I'm being compared to fertilizer. Well, I guess some of
my manure eventually turning into fetilizer.
>In fact, I keep a folder called Ideas where I stick
>stuff I'd like to expound upon someday, and your posts
>probably outnumber anyone else's.
My quantity is a good smoke screen for quality. I've been saving some of
Bela's old postings with the same idea in mind. Many people only bother
to supply the answers. Bela and few others supply the answer and how it
works. It's the how it works part that I find most interesting and
useful. In theory, if you understand how it works, and are reasonably
logical, the answers to most problems are fairly obvious.
>But the problem is
>usually as I explained above: I look at one, decide I don't
>really know enough about it, so I go search for something
>easier :-)
Well, the search for enlightenment blunders onward. I have the same
problem. I find that I learn more by explaining it to others, than I do
by RTFM. Some people learn by getting lectured, other from a book, some
need personal experience, but I learn by explaining. In any case, it's
slightly better than "Learn by Destroying".
Many years ago, I played technical editor on a Unix box. It was a
miserable experience. I decided that all the examples in the book should
actually work. Apparently, this was a new concept in Unix books, as
nobody agreed with such a radical concept. I'll never do it again.
Dinner at midnight again. Later...
Clint Zikesch
As we are now reliant on our DHCP server which is a Linux box we have a
backup server ready in case the running server dies. We copy all the
config files to it each night and if the worst happens have a script that
makes the backup look like the normal server. Of course this might not be
so practical for many servers but with Linux being free it was very
practical in this case. We thought about automating the process so that
it actually checked whether the primary was alive and if not became the
primary server all on it's own. However we thought this could lead to
further problems if we were just doing routine maintenance or a minor
problem in communication occurred.
Clint
Clint Zikesch
> Let's see if I understand this. You want a non-technical book on common
> sense enterprise management. Well, that would be a change. I could
> think of a few titles:
Pointers to technical info but in the right context is more what I was
thinking. Alot of people are putting the cart before the horse when trying
to manage a setup. Got the thing to run but don't know how to manage it so
it keeps running smoothly.
> Learn to RTFM in only 20 days.
>
Yes.. this one! I know you mean to say it's not possible but a goon like me
needs the right initial pointers to get going. I've got alot of admin
experience in a Novell context but moving to UNIX is scary in that I have to
accept all over again that I know nothing. Something aimed at a minimum
intermediate admin with a clue.
Even a simple topic list with lots of urls'/ISBN's/etc. combined with a few
scenario networks and administrive musts and a pre-requisite before you can
do this you must do/know this kinda thing. Maybe a suggested shopping list
of administrator tools & howto's. A clue on man-hours required to setup a
config on a per-node/user/pc basis, same for admin. A clue on relative
expenses of varying management strategies. I guess the sort of thing that
could take a tech to the level of a systems manager. Actually now that I
think a little harder this is impossible.
Never mind..
Well please just take it as a compliment then guys. I'm sure I could say
from everyone you're a great help to us all. Thanks.
Clint :)
Bill Vermillion
>> Let's see if I understand this. You want a non-technical book on
>> common sense enterprise management. Well, that would be a change.
>> I could think of a few titles:
>Pointers to technical info but in the right context is more what I
>was thinking. Alot of people are putting the cart before the horse
>when trying to manage a setup. Got the thing to run but don't know
>how to manage it so it keeps running smoothly.
>> Learn to RTFM in only 20 days.
>Yes.. this one! I know you mean to say it's not possible but a goon
>like me needs the right initial pointers to get going. I've got
>alot of admin experience in a Novell context but moving to UNIX is
>scary in that I have to accept all over again that I know nothing.
>Something aimed at a minimum intermediate admin with a clue.
Two recommendations. "Unix for the Impatient", and O'Reillys
CD ROM Bookshelf. The latter has "Power Tools" "Unix in a
Nutshell", "Learning the Korn Sehll", "sed & awk", "Learning vi"
and "Learning the Unix operating system", all on CD.
The 'impatient' book isn't quite what it's title implies.
It just has all the fluff removed and has a high signal/noise
ratio when compared to a lot of other in print today.
Others I'm sure will have other recommendations.
Bill
Bill
Simon Hobson
bi...@wjv.com.REMOVEME (Bill Vermillion) wrote:
>The fun will really begin when cheap NIC cards have user
>changeable MACs :-(
They already do !
D-Link cards had this a long time ago, all it needs is to fire up the
config program with a switch set to tell it your overiding the cards
settings and bingo, access to the MAC address. The switch is really there
in case the non volatile storage gets screwed up so the config program
barfs.
TTFN, Simon
Bill Vermillion
>They already do !
So now you can put in your bosses MAC address, and when his machine
is off, you can reboot your with his MAC and IP? To be secure
there you are probably going to need switches that lock a MAC
address to a specific port.
I can envision some serious problems because of this as the MAC is
the way machines communicate, using only the IP to find the MAC
address.