RE: [CentOS] Linux equivalent of 'format' in solaris
> It shows the physical disks on the server > > bash-2.05b# format > Searching for disks...done I like to use 'fdisk -l'. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] small window manager
> What is an alternative X window manager, supported by CentOS, > that has very small memory footprint? > > I want to avoid twm, because it defaults to interactive placement when > not giving geometry options. No other requirements. You found twm's 'RandomPlacment' unsuitable? -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 4 & autofs 4.1.3
For those of you using CentOS 4, is anyone having trouble with autofs 4.1.3? I'm seeing (with 60second unmount timeout) what appears to be an apparent race condition where a script touches an automount directory at about (the same second according to logs) the same time the unmount is triggered, and the script then gets a read error. Sure, increasing the unmount timeout will reduce the occurrence rate, but if this really is a race, then it won't eliminate it. In looking at the CHANGELOG between autofs 4.1.3 and 5.0.1rc2, there have been tons of changes including some references to timing issues. However nothing is jumping out, and there are many changes. Is it conventional wisdom that the 4.1.3 autofs has 'issues' and folks routinely move up to autofs 5 on CentOS 4.x? Thanks, -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] link speed
> Craig White írta: > > Is there a command line way to tell me whether a ethernet > connection is > > 100 BaseT or Gigabit Ethernet? > > mii-tool My experience with mii-tool on CentOS4 and 5 is that it won't show link speed above 100 even if it is. If the OP is trying to differentiate 100 vs. 1000, then I would suggest using ethtool instead. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] DKIM
> Okay, > Yahoo is bumming me. Only system my mail is having an issue > with. All mail > is accepted, but junked. I can only think it is the DKIM/Domain keys. Just a WAG, but make sure you have a PTR record for your machine that is sending email. If you actually got the bounce, check the headers, it is the first best place to look. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] DKIM
> Back to the PTR RR: > > $ dig +short MX bobhoffman.com > 10 mail.bobhoffman.com. > > $ dig +short A mail.bobhoffman.com > 72.35.68.59 > $ dig +short -x 72.35.68.59 > bobhoffman.com. > ^^^ > > mail.bobhoffman.com != bobhoffman.com Careful here. Email senders have nothing to do with MX records. Email receivers do. I believe bobhoffman.com is the email sender in this case. I would doubt this is an issue. Any split in/out mail server is going to have a different host for receipt (MX) than send. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] DKIM
> So his MTA is EHLOing as mail.bobhoffman.com > mail.bobhoffman.com resolves to 72.35.68.59 (matches the incoming ip) > 72.35.68.59 reverses to bobhoffman.com (which doesn't match the host) > > As far as I can tell this will hurt his score. > Or am I missing something? I don't know enough of the specifics of yahoo's scoring. However, in my experience it is better to have your sending host IP have a resolvable PTR record than not. I'm quickly loosing track of this thread, but it appears bobhoffman.com has that covered. As an aside, it would be my expectation that forward/reverse DNS literal matching wouldn't be scored highly (if at all) simply due to the common use of virtual hosting and the like, let alone the split in/out mail architecture already discussed. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] Re: ls and rm: "argument list too long"
> > rm -rf /var/amavis/tmp > > > > and get only "argument list too long" as feedback. > > > > Is there a way to go round this problem? > > > > I have CentOS 5.2. > > > It isn't a problem with the commands, it is a problem of how > long a command > line can be when piped to a command. > > rm -rf /var/amavis/tmp is effectively the same as rm -rf > /var/amavis/tmp/1 > /var/amavis/tmp/2 /var/amavis/tmp/3 /var/amavis/tmp/4 > /var/amavis/tmp/5 ... > etc. The number of diles and directories in that folder is > the limiting factor. I don't believe this is correct. The command "rm -rf /path/to/dir" doesn't expand on the shell the same way "rm -rf /path/to/dir/*" would. Unless I'm misunderstanding your comment, "rm -rf /path/to/dir" will remove everything as intended without blowing out the argument list. Dealing with file removal and getting 'argument list too long' is a FAQish question, and there is more than one way to get around the issue. Common workarounds include find piped to xargs rm, the above mentioned recursive directory nuke, one line perl scripts, etc. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] nfs slow?
> 2.) Use TCP, UDP Transmits are often slow these days. (mount > option tcp) Hmm, care to share any references for this? I'd be reaching for NFS over TCP in a long-haul type environment, but would run it over UDP otherwise. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
