On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote:
Yeah, I think it's an easy fix either in openrc or in an initscript
somewhere. I changed nothing except my kernel (was missing devtmpfs -- it's
not under Filesystems!), uninstalled module-init-tools, and installed kmod +
udev-181. Then rolled back the snapshot once I had the results.
When udev is linked against a library in /usr, this is not going to work
anymore, because udev won't start at all.
So you need need a smaller udev that is completely self contained and
make sure anything needed for the key rules works. I wonder if the
pci-ids cannot stay somewhere in /etc or /lib
lu
03-13-2012, 07:07 AM
Arch Website Notification
=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 3 packages missing signoffs
* 2 packages older than 14 days
(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)
== Incomplete signoffs for [community] (3 total) ==
=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 14 new packages in last 24 hours
* 2 known bad packages
* 0 packages not accepting signoffs
* 12 fully signed off packages
* 28 packages missing signoffs
* 5 packages older than 14 days
(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)
== New packages in [testing] in last 24 hours (14 total) ==
== All packages in [testing] for more than 14 days (5 total) ==
* libreoffice-i18n-3.5.0-1 (any), since 2012-02-10
* cups-filters-1.0.1-1 (i686), since 2012-02-17
* cups-filters-1.0.1-1 (x86_64), since 2012-02-17
* libreoffice-3.5.0-2 (i686), since 2012-02-20
* libreoffice-3.5.0-2 (x86_64), since 2012-02-20
On Mon, 12 Mar 2012 21:22:26 -0400
Joshua Kinard <kumba@gentoo.org> wrote:
> On a somewhat sarcastic note, why don't we just deprecate /usr and
> move everything back to /? Isn't that, largely, what is being
> accomplished here? Solaris at least keeps some kernel stuff in / off
> of /stand (I believe). Linux, after this /usr thing is fully
> complete, about the only thing left in / that is of any value will
> be /etc. Kernels were moved into /boot ages ago.
A bit like stali? http://sta.li/
Or is that still too complicated?
jer
03-13-2012, 10:21 AM
Bob Hoffman
*Nataraj*
/Tue Mar 13 02:01:36 EDT 2012/ wrote:
>On 03/12/2012 10:06 PM, Nataraj wrote:
>>/ On 03/12/2012 09:08 PM, Ron Loftin wrote:
/>>>/ I'm going to chuck in my 2 cents worth here, as I've been using Postfix
/>>>/ as a first-line filter for some years now.
//
/>pbl.spamhaus.org (dynamic IP address RBL) is generally quite safe for
>most sites to use from postfix. The rest of the spamhaus RBL's such as
>the combination that you get from zen.spamhaus.org are mostly safe
>(better than all others that I've tried), but not 100%. Most others
>that I've tried I have gotten a fair number of false positives over time
>(This includes dul.dnsbl.sorbs.net, the sorbs dynamic IP RBL). Many
>people feel that most other RBL's need to be used with a scoring
>mechanism, such as that provided by spamassasin, instead of directly
>from postfix to avoid getting too many false positives.
>Nataraj
I changed it a bit since then. I found that sleep 1, when talking to my other VM that had
sleep 1, caused one mail to just get lost, so I dropped it.
My brother travels a lot and I found the client restrictions would not allow him
to send mail since the wi-fi he would connect to was not figured correctly causing
100% mail send failure. So I left client restrictions empty, but I force ssl and user auth
only anyway.
for the rbl lists I tried to pick those that had a notice page and a remove page.
This way a blocked user can try to figure out why.
Here is a bit from my logwatch, with 8 hours of non blocked spam and 16 hours since blocking it
6098 rejected, 429 accepted (most of those 429 were before the change)
Since 12 noon yesterday I have received 17 junk mails, all but two tagged by spamasassin.
BIG DIFFERENCE.
Below is the logwatch section, followed by my final set up (at least so far).
3534 Connections made
419 Connections lost
3533 Disconnections
429 Removed from queue
137 Delivered
10 Sent via SMTP
1 Bounce (remote)
1 DSNs undeliverable
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
03-13-2012, 10:54 AM
James Broadhead
On 13 March 2012 01:22, Joshua Kinard <kumba@gentoo.org> wrote:
> We should be working to getting rid of /usr and bring it all back into /,
> then create temporary /usr symlinks to point programs in the right
> direction. *After all, /usr was originally for user data, not system data,
> until someone cooked up /home (I don't know the full exact history here, so
> feel free to correct me).
>
I believe that the Art of Unix Programming* says that /usr was the
result of the original UNIX 4MB hard disk becoming full, and that they
chose /usr to mount a second one. Every definition since then has been
an attempt to justify preserving the split.
* On reflection, I may have read this elsewhere.
03-13-2012, 12:36 PM
Ian Stakenvicius
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 12/03/12 11:14 PM, Joshua Kinard wrote:
> On 03/12/2012 22:33, Ian Stakenvicius wrote:
>
>>
>> On 2012-03-12, at 9:22 PM, Joshua Kinard <kumba@gentoo.org>
>> wrote:
>>
>>>
>>> And yes, I've already tested out udev-181 on a VM with a
>>> separate /usr. With devtmpfs, the system fully boots just
>>> fine, no initramfs needed. Guess what the only piece of
>>> software to mess up is? Udev. I largely think it's a timing
>>> issue in OpenRC, however, because /usr DOES get mounted fairly
>>> quickly, but not before udevd starts. But udevd does restart
>>> itself and everything looks to work fine. If you aren't
>>> watching the terminal, you wouldn't even notice the failures.
>>>
>>
>>
>> THANK YOU for testing this -- I could not forsee a reason, back
>> when this process started, as to why openrc couldn't mount /usr
>> before udev started. since devtmpfs should provide the source
>> devnode anyways. It's good to have a (near) proof of that.
>>
>> Ian
>
> Yeah, I think it's an easy fix either in openrc or in an initscript
> somewhere. I changed nothing except my kernel (was missing
> devtmpfs -- it's not under Filesystems!), uninstalled
> module-init-tools, and installed kmod + udev-181. Then rolled back
> the snapshot once I had the results.
Ah, right; kmod.. Tthere's pressure for that one to move to /usr
too, isn't there mgorny? .... ok, nvm.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard:
[...]
> After all, /usr was originally for user data, not system data,
> until someone cooked up /home (I don't know the full exact history here, so
> feel free to correct me).
IIRC usr = unified system resources (not an abbrev. for "user")
I want a process to be running with root*privileges, without providing the root password. Since i have my process in a remote machine. I want it such that, as soon as the system boots up, my process should be running with root privilege. Is there any way in which i can attain it?
Is there any possibility of forking c program as a child process of init process.If so please guide me on how to do it.
Thank You
--
Regards
Shreyas.M
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
03-13-2012, 04:17 PM
Nataraj
On 03/13/2012 04:21 AM, Bob Hoffman wrote:
> *Nataraj*
> /Tue Mar 13 02:01:36 EDT 2012/ wrote:
>
>> On 03/12/2012 10:06 PM, Nataraj wrote:
>>> / On 03/12/2012 09:08 PM, Ron Loftin wrote:
> />>>/ I'm going to chuck in my 2 cents worth here, as I've been using Postfix
> />>>/ as a first-line filter for some years now.
> //
> />pbl.spamhaus.org (dynamic IP address RBL) is generally quite safe for
>> most sites to use from postfix. The rest of the spamhaus RBL's such as
>> the combination that you get from zen.spamhaus.org are mostly safe
>> (better than all others that I've tried), but not 100%. Most others
>> that I've tried I have gotten a fair number of false positives over time
>> (This includes dul.dnsbl.sorbs.net, the sorbs dynamic IP RBL). Many
>> people feel that most other RBL's need to be used with a scoring
>> mechanism, such as that provided by spamassasin, instead of directly
> >from postfix to avoid getting too many false positives.
>
>> Nataraj
> I changed it a bit since then. I found that sleep 1, when talking to my other VM that had
> sleep 1, caused one mail to just get lost, so I dropped it.
>
> My brother travels a lot and I found the client restrictions would not allow him
> to send mail since the wi-fi he would connect to was not figured correctly causing
> 100% mail send failure. So I left client restrictions empty, but I force ssl and user auth
> only anyway.
Mobile clients should be authenticating to a relay that's not on any of
the dynamic lists and sending mail out through there. Most sane mail
administrators do not accept mail directly from dynamic broadband/mobile
clients.
> for the rbl lists I tried to pick those that had a notice page and a remove page.
> This way a blocked user can try to figure out why.
Also anyone using rbl's should also review the RBL's policy. Most RBL's
charge a license fee for high volume queries and will cut you off if you
violate their policy.
> Here is a bit from my logwatch, with 8 hours of non blocked spam and 16 hours since blocking it
> 6098 rejected, 429 accepted (most of those 429 were before the change)
> Since 12 noon yesterday I have received 17 junk mails, all but two tagged by spamasassin.
> BIG DIFFERENCE.
>
> Below is the logwatch section, followed by my final set up (at least so far).
Your logwatch format is very nice, that does not appear to be the
standard CentOS included logwatch. Have you customized it alot yourself?
In any case, I used to have very large numbers in the category you
described, but since I started doing agressive blocking with fail2ban
(matching on repeated mail delivery failures), now I just completely
block all those with IPtables, so that postfix never sees them. I have
not noticed any increase in user complaints since this happened. And I
do notice that the majority of the offending IP addresses were from
asia, south america, eastern Europe, the middle east, etc.
