Re: [gentoo-user] Re: odd /dev/null beharvior
According to: http://bugs.gentoo.org/show_bug.cgi?id=123249 The problem has been resolved. You should try # emerge sync # emerge -C udev # rm -f /etc/udev/permissions.d/50-udev.permissions # rm -f /etc/udev/rules.d/50-udev.rules # emerge -av udev If you still experience digest problems, reopen that bug and include any relevant information. -Chris -- Christopher Cowart Unix Systems Administrator Residential Computing, UC Berkeley "May all your pushes be popped" signature.asc Description: Digital signature
Re: [gentoo-user] Re: odd /dev/null beharvior
Sounds like this is related to the bug that's in an earlier thread.
Do as root:
# ebuild `equery which udev` digest
This will update the digest for now. The changes will be overwritten the
next time you sync portage, but it won't matter til the next time you
emerge udev. At which time, hopefully they'll have it fixed in portage.
-Chris
On 02:30 Tue 21 Feb , James wrote:
> Christopher Cowart rescomp.berkeley.edu> writes:
>
>
> > The easiest way to fix this problem permanently is to
> > $ sudo rm /etc/udev/{permissions,rules}.d/50-*
> > $ sudo emerge -av udev
>
> > This will blow away the default udev conf files that are causing you
> > problems, then re-emerge udev. The updated defaults will be installed in
> > the right place. This assumes you haven't touched the 50-* files (you
> > put all custom changes in 10-local, right).
>
>
> Nope, Here's what I get:
>
> !!! Digest verification Failed:
> !!!/usr/portage/sys-fs/udev/files/udev.permissions
> !!! Reason: Filesize does not match recorded size
>
> >>> Please ensure you have sync'd properly. Please try 'emerge sync' and
> >>> optionally examine the file(s) for corruption. A sync will fix most cases.
>
>
> Now I've unmerge udev, and sync'd twice
>
> Ideas?
>
>
> James
>
>
>
> --
> gentoo-user@gentoo.org mailing list
>
--
Christopher Cowart
Unix Systems Administrator
Residential Computing, UC Berkeley
"May all your pushes be popped"
signature.asc
Description: Digital signature
Re: [gentoo-user] KMail and GnuPG plugin
Add the following lines to ~/.gnupg/gpg.conf: keyserver x-hkp://pgp.mit.edu keyserver-options auto-key-retrieve include-disabled include-revoked \ honor-keyserver-url (Except don't break the line in your conf) The keyserver-option "auto-key-retrieve" tells gpg to try to get a key from a keyserver whenever it's verifying a message but lacks the public key on your keyring. You can check 'man gpg' for more information about tweaking gpg's behavior, but the options above will probably be just fine for your use. -Chris On 17:33 Sat 18 Feb , Rafael Bugajewski wrote: > Hi all, > > I have a problem with KMail regarding the GnuPG plugin. I think i just do not > know how to use it and where to find documentation, so a little help would be > useful. > > The plugin itself works fine, I can send encrypted and signed messages, I get > always a prompt in which I can enter my passphrase etc. > > My only problem is if I receive signed messages from unknown identities. > KMail > puts the whole message into a yellow box and says that there is a unknown > key. There is no possibility to search for the key and insert it, or is it > and I do not know about it? It would be nice to add new keys directly from > the KMail interface. If it is not possible, what is the fastest _and_ most > user friendly way? > > Greets, > > Rafael Bugajewski -- Christopher Cowart Unix Systems Administrator Residential Computing, UC Berkeley "May all your pushes be popped" signature.asc Description: Digital signature
Re: [gentoo-user] odd /dev/null beharvior
I've experienced this problem before. The developers insist the ebuild
is absolutely correct, but it doesn't always attempt to migrate conf
changes to /etc/udev.
The easiest way to fix this problem permanently is to
$ sudo rm /etc/udev/{permissions,rules}.d/50-*
$ sudo emerge -av udev
This will blow away the default udev conf files that are causing you
problems, then re-emerge udev. The updated defaults will be installed in
the right place. This assumes you haven't touched the 50-* files (you
put all custom changes in 10-local, right).
-Chris
On 16:46 Sat 18 Feb , James wrote:
> Hello,
>
> /dev/null is acting weird. The permissions have recently changes
> on a system I sync regularly. I can change the permissions back
> to 666, but every time the system reboots, dev null resets to:
> crw-rw 1 root 1, 3 Jan 20 10:05 /dev/null
>
> How to I make permanent changes so that /dev/null is 666 again?
>
> Surely this is not part of some security issue that I missed?
>
> James
>
>
>
> --
> gentoo-user@gentoo.org mailing list
>
--
Christopher Cowart
Unix Systems Administrator
Residential Computing, UC Berkeley
"May all your pushes be popped"
signature.asc
Description: Digital signature
Re: [gentoo-user] Re: Unable to locate mail
> Thanks Chris, I never understood this [EMAIL PROTECTED] (probably because I > have inadequate knowledge of many matters relating to mail within an OS). > Where is [EMAIL PROTECTED], where is mail for [EMAIL PROTECTED] stored, how > is it > meant to be retrieved? localhost means your box. Any network traffic destined for the localhost goes through the "loopback device" and shows up right where it left. localhost resolves to 127.0.0.1, as you'll notice in any default /etc/hosts. If you have sshd running on a box, you can "ssh localhost". If you have apache running, you could type in your browser "http://localhost/";. Using localhost works on Windows too... Most importantly (to this discussion) ... > Is this meant to be a real (external) mail server e.g. smtp.my_isp.com, or > is there a Linux OS setup I can use internally without mail leaving the > box? If you have an MTA (Mail transfer agent) running on your box, you can relay e-mail through your localhost. However, chances are you don't want to run a full-blown MTA, not even to deliver root e-mails. These programs would include postfix, exim, and sendmail. Although it can be quite trivial to restrict traffic to your localhost, an MTA like postfix is really overkill for a personal computer. Instead, you can configure ssmtp to relay through somebody elses' SMTP server. The problem is that if you e-mail something to "[EMAIL PROTECTED]", but connect to smtp.yourisp.com, localhost still means "127.0.0.1," which as far as smtp.yourisp.com is concerned, is /their/ localhost, not yours. Thus, you implement a reverse alias in /etc/ssmtp/revaliases. That way, any outgoing mail destined for root, the headers can be rewritten to have it sent to [EMAIL PROTECTED] So, if you're not running an smtp server on your localhost (and you probably don't need to be... shouldn't be), you could relay through your ISP. But, you may not want clear text about problems with your machine flying around the internet... It does raise security concerns, but you're probably ok to do it. -Chris -- Christopher Cowart Unix Systems Administrator Residential Computing, UC Berkeley "May all your pushes be popped" signature.asc Description: Digital signature
Re: [gentoo-user] Unable to locate mail
If a cron generates any output while it's running, it tries to email it to [EMAIL PROTECTED] ssmtp is your default MTA, and it's default configuration points to the host mail, at port 25. As mail doesn't resolve to any mail server, that's the sSMTP error you're seeing. If you don't want cron mails, you can redirect ( > ) the output to a file or /dev/null. You could also configure sSMTP to have a reverse alias, so that when it tries to e-mail root, it'll e-mail [EMAIL PROTECTED] This would involve also changing sSMTP to be aware of your ISP's mail hub. -Chris On 20:58 Fri 17 Feb , Michael Kintzios wrote: > Hi All, > > I have not (knowingly) set up my syslog-ng, logrotate, or some other > application to send me mail, so I am curious where this little message came > from: > === > Feb 17 20:10:02 study1 cron[12102]: (root) CMD (test -x /usr/sbin/run-crons > && /usr/sbin/run-crons ) > Feb 17 20:11:58 study1 sSMTP[12061]: Unable to locate mail > Feb 17 20:11:58 study1 sSMTP[12061]: Cannot open mail:25 > Feb 17 20:11:58 study1 cron[12047]: (root) MAIL (mailed 69 bytes of output > but got status 0x0001 ) > Feb 17 20:20:01 study1 cron[12132]: (root) CMD (test -x /usr/sbin/run-crons > && /usr/sbin/run-crons ) > Feb 17 20:30:01 study1 cron[12144]: (root) CMD (test -x /usr/sbin/run-crons > && /usr/sbin/run-crons ) > === > > Any ideas? > -- > Regards, > Mick > -- Christopher Cowart Unix Systems Administrator Residential Computing, UC Berkeley "May all your pushes be popped" signature.asc Description: Digital signature
