RE: [vox-tech] Another Round of eth0 Problemas - Fixed, now how t o prevent?
Ken Herron wrote: It sounds like you might have another computer on your LAN using the same IP address. Ken wins! The problem turned out to be someone else in IT was bringing a new printer online with the same IP address. Doh! I discovered this when I entered http://mmagdb/ for the 122nd time, and instead of serving up the redirect from Apache, the Plone site, or nothing at all, an HP printer status page from the offending piece of equipment came up with confirmation of the duplicate IP. The printer was promptly brought down and everything seems to be working as expected. Our WAN guy maintains that he checked for duplicate IP addresses. Why do the little things cause the biggest headaches? This is the second time I've run into duplicate IP address problems on this network. The static IPs are mixed into the same host range with the DHCP licensed IPs and IT's system for organizing them or notifying all personnel of IP assignments has failed. It like they just hijack a number and don't even ping for a response. I heard there's an Excel file somewhere that has the reserved static IP addresses on it but changes to the file are not propagated to everyone in the IT group. Huh? There's gotta be a better way... I spent the better part of the last 5 days fretting about this problem which turned out to be because of lack of communication by IT. (Of course, if I knew better, I should have explored that possibility further.) I plan to address this with the parties involved, but instead of just ripping into them I want to bring suggestions to the table. It's not my job to do either of those but it's for their own good, since the next time they knock this server out, the downtime will be far more expensive and they will get kicked with a bigger boot from management. So, if I may redirect the discussion, I'd like to hear about how the network admins on the list organize IP assignments. More specifically, is it wise to put static IPs shuffled within the DHCP licensed host range and simply blacklist the statics from the DHCP server? Why not put the static IPs in a different network, that way the address itself would tell you the address type (static vs. dynamic) and if partitioned out even further, printers could be in one host range on the network ,and servers could be in another. Is it common to just ping addresses to find an unused one and then grab it? Or is this a non-issue and only newbies and hacks are affected by it? Once again, this mailing list has proven to be a useful resource. Many heads are indeed better than one. Regards, Joey ~~ Joseph Karalius Research Associate - Bioinformatics Molecular Markers and Applied Genomics Seminis Vegetable Seeds, Inc 37437 State Highway 16 Woodland, CA 95695-9353 530-669-6131 joseph.karalius (a) seminis dot com ~~ ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
RE: [vox-tech] Another Round of eth0 Problemas - Fixed, now how t o prevent?
On Thu, 3 Mar 2005, Karalius, Joseph wrote: Ken Herron wrote: It sounds like you might have another computer on your LAN using the same IP address. Ken wins! The problem turned out to be someone else in IT was bringing a new printer online with the same IP address. Doh! ... 20/20 I discovered this when I entered http://mmagdb/ for the 122nd time, and instead of serving up the redirect from Apache, the Plone site, or nothing at all, an HP printer status page from the offending piece of equipment came up with confirmation of the duplicate IP. The printer was promptly brought down and everything seems to be working as expected. Our WAN guy maintains that he checked for duplicate IP addresses. He checked? Since the switch responds to whichever device sent a packet last, and the printer won't be emitting as many packets as an intranet server, the switch is likely to point to the server most of the time. Why do the little things cause the biggest headaches? This is the second time I've run into duplicate IP address problems on this network. The static IPs are mixed into the same host range with the DHCP licensed IPs and IT's system for organizing them or notifying all personnel of IP assignments has failed. It like they just hijack a number and don't even ping for a response. I heard there's an Excel file somewhere that has the reserved static IP addresses on it but changes to the file are not propagated to everyone in the IT group. Huh? There's gotta be a better way... Yes and no. If someone who thinks they know what is going on hijacks a number, you can't stop them. You have to have the cooperation of people using the network. I spent the better part of the last 5 days fretting about this problem which turned out to be because of lack of communication by IT. (Of course, if I knew better, I should have explored that possibility further.) I plan to address this with the parties involved, but instead of just ripping into them I want to bring suggestions to the table. It's not my job to do either of those but it's for their own good, since the next time they knock this server out, the downtime will be far more expensive and they will get kicked with a bigger boot from management. So, if I may redirect the discussion, I'd like to hear about how the network admins on the list organize IP assignments. More specifically, is it wise to put static IPs shuffled within the DHCP licensed host range and simply blacklist the statics from the DHCP server? Unwise... and unusual. Why not put the static IPs in a different network, that way the address itself would tell you the address type (static vs. dynamic) and if partitioned out even further, printers could be in one host range on the network ,and servers could be in another. Not a different network, since that would imply different broadcast addresses... but you can use convention to subdivide the network. DHCP servers are specifically configurable to allow the administrator to set aside a range for allocating dynamic ip addresses. I setup a range for statics (usually near the bottom of the network address range), then a range for dynamic leases (near the top) and a third range for MAC-allocated DHCP addresses in the middle somewhere. Is it common to just ping addresses to find an unused one and then grab it? Common? depends which idiot is handing out the advice. Or is this a non-issue and only newbies and hacks are affected by it? It is always an issue as an organization grows larger. I don't manage a large network so I don't speak from experience, but I would advocate a visible, public (within the organization) document like a web page for making the policy clear and providing instructions for who to talk to about adding equipment that doesn't use DHCP. I think it is important to enlist people's cooperation, because failing to do so leads to these problems. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k --- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
RE: [vox-tech] Another Round of eth0 Problemas - Fixed, now how t o prevent?
On Thu, 3 Mar 2005, Karalius, Joseph wrote: [snip] So, if I may redirect the discussion, I'd like to hear about how the network admins on the list organize IP assignments. More specifically, is it wise to put static IPs shuffled within the DHCP licensed host range and simply blacklist the statics from the DHCP server? Why not put the static IPs in a different network, that way the address itself would tell you the address type (static vs. dynamic) and if partitioned out even further, printers could be in one host range on the network ,and servers could be in another. Is it common to just ping addresses to find an unused one and then grab it? Or is this a non-issue and only newbies and hacks are affected by it? Wouldn't it be easier to move the DHCP to a new network address than to move the static addresses, since all DHCP's IP addresses can be moved from the server? Set the netmask on the new DHCP addresses to include the static IP address range, and announce to everyone to set any computers with static IP addresses to use the new mask. If anyone comes to IT and complains about their computer not being able to access certain others, then the IT has identified a rogue static IP address user, and can switch them over to DHCP. Really, though, nobody should be using static IP address. If they need to act as a server, they can do a MAC-address based DHCP resolution to always get the same IP address. To do that, they'd have to get someone in the IT to make a list of NICs that want to have static addresses, and they'd enter that into the DHCP server somewhere to always give them the same IP address. This will centralize all IP assignment to the DHCP server and remove all IP address conflict altogether (until someone stupidly plugs in a computer and gives it a static IP.) -Mark -- Mark K. Kim AIM: markus kimius Homepage: http://www.cbreak.org/ Xanga: http://www.xanga.com/vindaci Friendster: http://www.friendster.com/user.php?uid=13046 PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE PGP key available on the homepage ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] another PS2PDF question [solved]
On Monday 28 February 2005 02:45 pm, Jonathan Stickel wrote: [snip] Using my suggested hack, try epstopdf foo.pdf, i.e. allow the default compression flag to stay on. You should get a compressed (smaller) file, but the image should still be crisp. Thanks for the suggestions. My PDF files are beingcreated quite nicely now! The best doc I can find is http://www.cs.wisc.edu/~ghost/doc/gnu/7.05/Ps2pdf.htm. This, with trial and error, lead me to my suggestion above. From what I can tell, the prepress setting has the same color image encoding options as the others, so I don't think the results will be much different. That website was a good start, however it is lacking information on the more finer points of PDF creation. I did a little more digging , and here is what I found; this website: http://www.texnik.de/hyperref/hyperref.phtml has a lot of nice details on PDF creation in general. Also, it is possible to change the default GS PDF creation behavior here; /usr/share/gs-gpl/8.01/lib/gs_pdfwr.ps Cheers! -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
RE: [vox-tech] Another Round of eth0 Problemas - Fixed, now how t o prevent?
On Thu, 3 Mar 2005, Mark K. Kim wrote: On Thu, 3 Mar 2005, Karalius, Joseph wrote: [snip] So, if I may redirect the discussion, I'd like to hear about how the network admins on the list organize IP assignments. More specifically, is it wise to put static IPs shuffled within the DHCP licensed host range and simply blacklist the statics from the DHCP server? Why not put the static IPs in a different network, that way the address itself would tell you the address type (static vs. dynamic) and if partitioned out even further, printers could be in one host range on the network ,and servers could be in another. Is it common to just ping addresses to find an unused one and then grab it? Or is this a non-issue and only newbies and hacks are affected by it? Wouldn't it be easier to move the DHCP to a new network address than to move the static addresses, since all DHCP's IP addresses can be moved from the server? Set the netmask on the new DHCP addresses to include the static IP address range, and announce to everyone to set any computers with static IP addresses to use the new mask. If anyone comes to IT and complains about their computer not being able to access certain others, then the IT has identified a rogue static IP address user, and can switch them over to DHCP. I think the case in point contradicts your argument... Joey wasn't at fault. Really, though, nobody should be using static IP address. If they need to act as a server, they can do a MAC-address based DHCP resolution to always get the same IP address. To do that, they'd have to get someone in the IT to make a list of NICs that want to have static addresses, and they'd enter that into the DHCP server somewhere to always give them the same IP address. This will centralize all IP assignment to the DHCP server and remove all IP address conflict altogether (until someone stupidly plugs in a computer and gives it a static IP.) I agree that in most cases this is true... but there are some devices that just don't work well with DHCP, so you have to assign them statically. (That doesn't preclude you from ALSO giving it the same address via a MAC-assigned DHCP lease as a bookkeeping measure, but then you probably wouldn't remember that it was in fact statically assigned.) --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k --- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
RE: [vox-tech] Another Round of eth0 Problemas - Fixed, now how t o prevent?
Some good suggestions. The solutions are all quite simple, it basically a matter of getting everybody on the same page. I'll run these ideas by the appropriate decision-makers and cross my fingers. Thanks again to everyone involved, Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Newmiller Sent: Thursday, March 03, 2005 11:03 AM To: lugod's technical discussion forum Subject: RE: [vox-tech] Another Round of eth0 Problemas - Fixed, now how t o prevent? On Thu, 3 Mar 2005, Mark K. Kim wrote: On Thu, 3 Mar 2005, Karalius, Joseph wrote: [snip] So, if I may redirect the discussion, I'd like to hear about how the network admins on the list organize IP assignments. More specifically, is it wise to put static IPs shuffled within the DHCP licensed host range and simply blacklist the statics from the DHCP server? Why not put the static IPs in a different network, that way the address itself would tell you the address type (static vs. dynamic) and if partitioned out even further, printers could be in one host range on the network ,and servers could be in another. Is it common to just ping addresses to find an unused one and then grab it? Or is this a non-issue and only newbies and hacks are affected by it? Wouldn't it be easier to move the DHCP to a new network address than to move the static addresses, since all DHCP's IP addresses can be moved from the server? Set the netmask on the new DHCP addresses to include the static IP address range, and announce to everyone to set any computers with static IP addresses to use the new mask. If anyone comes to IT and complains about their computer not being able to access certain others, then the IT has identified a rogue static IP address user, and can switch them over to DHCP. I think the case in point contradicts your argument... Joey wasn't at fault. Really, though, nobody should be using static IP address. If they need to act as a server, they can do a MAC-address based DHCP resolution to always get the same IP address. To do that, they'd have to get someone in the IT to make a list of NICs that want to have static addresses, and they'd enter that into the DHCP server somewhere to always give them the same IP address. This will centralize all IP assignment to the DHCP server and remove all IP address conflict altogether (until someone stupidly plugs in a computer and gives it a static IP.) I agree that in most cases this is true... but there are some devices that just don't work well with DHCP, so you have to assign them statically. (That doesn't preclude you from ALSO giving it the same address via a MAC-assigned DHCP lease as a bookkeeping measure, but then you probably wouldn't remember that it was in fact statically assigned.) -- - Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k -- - ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] Changing Debian Screen Resolution
My Debian screen resolution defaults to a bothersome 800x600. I'm trying to get it to 1024x768. If I use xf86cfg and choose 1024x768 nothing changes. If I type xrandr -s 1024x768 then the resolution changes for the current session only. When I reboot I go back to 800x600. So, can anybody tell me how to make the 1024x768 screen resolution permanent? Thank you. Bob P.S. Am I the only Debian hating Debian user in the world? ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Changing Debian Screen Resolution
On Thu, Mar 03, 2005 at 05:27:18PM -0800, Robert G. Scofield wrote: My Debian screen resolution defaults to a bothersome 800x600. I'm trying to get it to 1024x768. So, can anybody tell me how to make the 1024x768 screen resolution permanent? You're /etc/X11/XF86Config[-4] should look like: Section Screen Identifier screen Device device Monitor monitor DefaultDepth24 SubSection Display Depth 24 Modes 1024x768 EndSubSection EndSection ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Changing Debian Screen Resolution
On Thu, Mar 03, 2005 at 05:27:18PM -0800, Robert G. Scofield wrote: My Debian screen resolution defaults to a bothersome 800x600. I'm trying to get it to 1024x768. If I use xf86cfg and choose 1024x768 nothing changes. If I type xrandr -s 1024x768 then the resolution changes for the current session only. When I reboot I go back to 800x600. So, can anybody tell me how to make the 1024x768 screen resolution permanent? Thank you. Bob P.S. Am I the only Debian hating Debian user in the world? Edit your /etc/X11/XF86Config-4 find Section Screen then find the Subsection Display which corresponds to the default color depth. Add 1024x768 at the beginning of the Modes line. --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. signature.asc Description: Digital signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Changing Debian Screen Resolution
On Thursday 03 March 2005 17:33, Ken Bloom wrote: Edit your /etc/X11/XF86Config-4 find Section Screen then find the Subsection Display which corresponds to the default color depth. Add 1024x768 at the beginning of the Modes line. First let me say thanks Ken and thanks David. Believe it or not, the solution does not work. I ended up modifying the resolution for all color depth entries. I added 1024x768 and removed all other resolutions. Here's what happens when I reboot. When X starts the bottom one fifth of the screen becomes a black band. The the screen blinks, and you see a small mouse pointer indicating that the resolution is 1024x768. But then the screen blinks again and the mouse arrow is big indicating that I'm back at 800x600. GNOME continues to boot, and there I am in 800x600. Now here's another mystery. When I type xandr I'm given about 4 screen resolutions. This is interesting since XFConfig-4 has only one; 1024x768. What's more xandr has an asterisk indicating that my resolution is set at 800x600. I'm wondering if something is overriding XF86Config-4. Could GDM be doing something? Here's another thought. You might remember several weeks ago when I was trying to set up X. I was trying to follow the directions for an outdated version of X. I'm wondering if I may have set up another configuration file like you used to do before Linux started using XFConfig-4. Does anybody have any thoughts about this? In the meantime I'll start looking for another configuration file that I may have set up. Bob ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Changing Debian Screen Resolution
On Thursday 03 March 2005 22:53, Robert G. Scofield wrote: I'm wondering if something is overriding XF86Config-4. Could GDM be doing something? Here's another thought. You might remember several weeks ago when I was trying to set up X. I was trying to follow the directions for an outdated version of X. I'm wondering if I may have set up another configuration file like you used to do before Linux started using XFConfig-4. Okay, I seem to have it running. I checked my notes and discovered that my attempt to create an outdated config file was done on an earlier Sarge install attempt. There were no outdated config files on my present Debian system. GNOME was the problem. Under Desktop Preferences there was a selection for screen resolution. That screen resolution was set for 800x600. I still get that funny band when I boot, but it's blue instead of black now. Nevertheless, I've got 1024x678 resolution. Thanks for the help. Bob ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Changing Debian Screen Resolution
On Thu, Mar 03, 2005 at 05:33:12PM -0800, Ken Bloom wrote: Edit your /etc/X11/XF86Config-4 find Section Screen then find the Subsection Display which corresponds to the default color depth. Add 1024x768 at the beginning of the Modes line. Be careful editing XF86Config-4 by hand if debconf is managing it. An apt-get upgrade and a thoughtless [Y]es, overwrite can end up killing any changes you made by hand. :^) If you can get it working with dpkg-reconfigure xserver-xfree86, all the better. Or, just don't debconf it. (I don't recall how to do that off the top of my head, though!) -bill! What? No... I'm not speaking out of experience! *blush* Don't be silly! ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
