Re: Default value for UIDs
On Tue, Jun 28, 2011 at 06:30:23PM +0100, Chris Rees wrote: On 28 June 2011 17:59, Dan Nelson dnel...@allantgroup.com wrote: In the last episode (Jun 28), Chris Rees said: Hi all, [crees@zeus]~% tail -n 2 /usr/ports/UIDs dbxml:*:949:949::0:0:dbXML user:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin [crees@zeus]~% grep crees /etc/passwd crees:*:1001:1001:Chris Rees:/home/crees:/bin/tcsh chris:*:1001:1001:Chris Rees:/home/crees:/bin/tcsh [crees@zeus]~% I'm a little concerned at how close the ports UIDs are getting to the username space... There are only 216 entries in UIDs, though, so if people are just using last entry + 1 when adding new ones, they should probably start filling the gaps instead. The 100s and 200s are pretty dense, but 350-399 only has 5 entries, 400-499 has 4, 600-699 has 7, 700-799 has 3, etc. Thank you for pointing that out (d'oh). However, perhaps we could still address the *potential* problems. To use one example, Debian has (as long as I can remember) used 10001 for the first username. When we have 65535 - 99 UIDs to play with, expansion like this isn't a problem. Could it be worth it? Think of ten years down the line. Best part would be to find every port that doesnt need a statically allocated UID/GID and just dynamically allocate them after a certain range '3-5' or whatever for ~20,000 ports and divide that namespace up by category. dbxml really does it really need to be static ? it just needs to run. Also: (stable/8) /usr/ports/UIDs dbxml:*:945:945::0:0: user:/nonexistent:/sbin/nologin dbxml:*:949:949::0:0:dbXML user:/nonexistent:/sbin/nologin Which one of these are we planning on actually using here ? git, hg, undernet, vboxusers... for example. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How can process in STOP state consume 200% CPU?
On Tue, Jun 28, 2011 at 11:40:29AM -0700, Yuri wrote: I got VirtualBox process in a strange state. It has the status STOP but shows by top as consuming 200% CPU for a very long time. How is this possible and what does this mean? Process time stays at 0:00 TIME. kill -9 doesn't kill it. kill -CONT PID USERNAME THR PRI NICE SIZERES STATE C TIMECPU COMMAND 9390 yuri3 440 508M 246M STOP3 0:00 200.00% VirtualBox ... 8.2-STABLE I would suppose that because you stopped the clients frontend that the backend has not been notified and is doing its best to draw to the screen causing a high CPU usage. Though you have used -STOP on the process youll still have to -CONT after the -KILL for it to actually exit since the process is effectively stopped its not going to abide by any further signals until it recieves -CONT. Anyway now you know not to use -STOP on that process ;) Is it supposed to do anything with the stop signal ? has it been documented in VB ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Question about FreeBSD and long usernames
On Wed, Jan 19, 2011 at 04:04:04PM +0100, Mateusz Kwiatkowski wrote: Hi, I have noticed inconsistent behaviour of some tools while working with long usernames. I dont get why you would need or want to work with longer usernames but if that is your goal then lets continue below... At first, 17 chars username (UT_NAMESIZE is set to 16, MAXLOGNAME to 17): # pw user add verylongusername pwd_mkdb: jira_pawprintgames: username too long The problem here is not ``verylongusername'' thats exactly 16 characters in the U.S. not sure where you think the other 2 characters came from. jira_pawprintgames: is 18 characters long and that is where pw(8) is bailing out. Utility is working correctly as it should here. But it is possible to create such user with vipw: # id verylongusername uid=1005(verylongusername) gid=1003(users) groups=1003(users) As stated above your not adding a very long user name here, but vipw is exactly of the type (editor) does not really need to verify what your putting into the file and shouldnt... its editing and if you have added a user name that long then its a failure on the admins part for doing so. We can make use of this account: su - verylongusername % id uid=1005(verylongusername) gid=1003(users) groups=1003(users) I sure hope so its 16 charaters long. # passwd verylongusername Changing local password for verylongusername New Password: Retype New Password: # Same as previous statement. 18 chars username: # id verylongusername1 uid=1006(verylongusername1) gid=1003(users) groups=1003(users) # su - verylongusername1 su: username too long This is 17 characters, you are now exactly 1 character past the limit and this is where you start seeing failures and think it is an inconsistancy though everything before was correct except ``jira_pawprintgames'' # sudo -u verylongusername1 id uid=1006(verylongusername1) gid=1003(users) groups=1003(users) This is not of the base system, though the maintainer may be interested in a patch that makes this cooperate with the standard maximum length of a username. It may just be that sudo(1) is just mapping to the UID GID here rather than checking lenght. It's possible to change password: # passwd verylongusername1 Changing local password for verylongusername1 New Password: Retype New Password: # It is not passwd's job to determine what it can and cannot set a password on so even in this situation if you have managed to vipw(8) and add a user with astronomical length, it is not the utilities fault its PEBKAC. When trying to login with ssh (17 chars username worked ok): Jan 19 14:46:08 sshd[39050]: setlogin(verylongusername1): Invalid argument Why some tools deny using long usernames, while others permit? Should it be corrected? I do not see a problem at all using a correct length and not trying to force a username into the passwd by means of vipw(8). -- Regards, J. Hellenthal JJH48-ARIN 0x89D8547E pgpIMQGouYpIU.pgp Description: PGP signature
Re: Switching to [KMGTPE]i prefixes?
On Fri, Mar 25, 2011 at 10:13:04AM +, Alexander Best wrote: On Fri Mar 25 11, Bruce Cran wrote: On Fri, 25 Mar 2011 00:21:15 + Alexander Best arun...@freebsd.org wrote: i hacked up humanized_number(3) a bit in order to produce the following df(1) output: [...] 4.2Gi 4.2Gi 0B 100% 0 0 100% /media/dvd I don't know if it's correct, but Snow Leopard uses Bi for bytes. hmmm...i'm wondering why they do that. there's no reason for that, because 1 bytes is 8 bit no matter if you use a power of one or a power of ten. Given the output above it would only be safe to assume that you are refering to a BLOCKSIZE=K when denoting size as Gi. It would be more proper if this was to denote the size as GiB so the end result can be determined whether or not it is really Gib. [X]i in it self does not signify the size of the data by which the result was calculated but only that the result has been calculated by 1024^N and seems to have been a mislead representation by other OS's. So whether were using BLOCKSIZE of b B K M G T P... can we adjust this so it displays the increment correctly please ? http://en.wikipedia.org/wiki/Byte http://en.wikipedia.org/wiki/Megabyte http://en.wikipedia.org/wiki/Gigabyte [...] http://en.wikipedia.org/wiki/Template:Quantities_of_bits http://en.wikipedia.org/wiki/Orders_of_magnitude_%28data%29 -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN pgpTCRbGNbhb2.pgp Description: PGP signature
Re: setsid not found on freebsd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 14 Feb 2011 16:37, arved@ wrote:
On Feb 14, 2011, at 08:46 , Ashish Mahamuni wrote:
I am using FreeBSD 8.1.
I am doing some automation stuff and running shell scripts remotely using
setsid command.
It seems that I do not have setsid on my system. Also, searched in
/usr/ports for installation but no luck.
Could you please tell me the way to install this command or may be the
alternative?
I used a very simple implementation in one of my ports.
/usr/ports/net/nxproxy/files/setsid.c
HTH
arved
Yeah it is not very hard to grab the source yourself and do a little
modification.
gcc -O2 -o setsid setsid.c
modified for your enjoyment...
Regards,
- --
jhell
-BEGIN PGP SIGNATURE-
Comment: THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
Comment: ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
Comment: FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
Comment: LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY
Comment: OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
Comment: SUCH DAMAGE.
iQEcBAEBAgAGBQJNWhd+AAoJEJBXh4mJ2FR++4wIAIKYp6uZH4VxKRv5JwkULg0H
zezyaM9p49DJkJCobRJJLYmy7NuUfQRfvlMTNCJPJM4PnzPy7MgX5U+5xpl8Mdnm
Yd5vWs3V9a8hPjTiP2YVqBjWRIxB1/j8/2BbfllrY2GUdGtr0cdyHmwSr3VuoXZH
4/7+a/TkadeLbR3pEnHk5fX3nkdhXViVyQb/QRF4PVfn3w8elO6RrzLHYV694DgB
BF3pn8lmrWASh6vhI80SSzJIKAFBlFs3dtuWYwjIbuuoSDtOHwNci1lstmEfat+e
8AtF0KZLMXDFjJvjkEQ6DeRdTKsc1o5x/+umJWsDspm9iKrj+NA21PmTZVBfHjs=
=1Ut0
-END PGP SIGNATURE-/*
* setsid.c -- execute a command in a new session
* Rick Sladkey j...@world.std.com
* In the public domain.
*
* 1999-02-22 Arkadiusz Mi¶kiewicz mis...@pld.org.pl
* - added Native Language Support
*
* 2001-01-18 John Fremlin v...@penguinpowered.com
* - fork in case we are process group leader
*
* 2011-02-14 Jason J. Hellenthal jh...@dataix.net
* - removed nls support for this simple command.
*
*/
#include stdio.h
#include unistd.h
#include stdlib.h
#define _(Text) (Text)
int
main(int argc, char *argv[]) {
if (argc 2) {
fprintf(stderr, _(usage: %s program [arg ...]\n),
argv[0]);
exit(1);
}
if (getpgrp() == getpid()) {
switch(fork()){
case -1:
perror(fork);
exit(1);
case 0: /* child */
break;
default:/* parent */
exit(0);
}
}
if (setsid() 0) {
perror(setsid); /* cannot happen */
exit(1);
}
execvp(argv[1], argv + 1);
perror(execvp);
exit(1);
}
-BEGIN PGP SIGNATURE-
Comment: THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
Comment: ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
Comment: FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
Comment: LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY
Comment: OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
Comment: SUCH DAMAGE.
iQEcBAABAgAGBQJNWhUSAAoJEJBXh4mJ2FR+ZCAH/j7DDNzaajla2Xa7GjY44Frq
sMFN3NN9FyIR5Zk6W557X5Tx3VhzsoFPHE9T0O49iox/180+DdRBEjpaP4t5VlVv
JhxI9KYUWAlX9LXnm5ONv1Awem3wzQMHkQ5aA5Pb12DMg0GgZkDJ9sn3m+vdANTl
/uJV5KyqK8z1Pqxaa1TTezQYbfTnh6u6DRFotF7ZOm2v9hyVW6ZxSYO69bwQ7wku
EpUKjwtRXFexLp1qrl3M2OZoV4+14yGniueo9lEfSMvHwm+mAzXn6gqo3UptSFQ1
azzuZt5v3Y4lxkrtk0MWcCUF8x1ae+WL0hEzajzlck7jLSROwtMxZuv4wMhzvew=
=MXFs
-END PGP SIGNATURE-
MD5 (setsid.c) = 2cdca47ac79c63d81b72d65218c5bdae
SHA256 (setsid.c) =
66dcbe4e5c1986e61e2b78dba2f9a6388646fc44ffa93d7ea43b192747a77523
SIZE (setsid.c) = 941
.\ Rick Sladkey j...@world.std.com
.\ In the public domain.
.\ Path modifications by fa...@cs.unc.edu
.TH SETSID 1 20 November 1993 Linux 0.99 Linux Programmer's Manual
.SH NAME
setsid \- run a program in a new session
.SH SYNOPSIS
.B setsid
.I program
.RI [ arg ...]
.SH
Re: Kernel panic
On 11/12/2010 16:41, mezgani ali wrote: Hello, I compiled a custom kernel, and i got this error message : Root mount waiting for: usbbus3 uhub3: 8ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad0s1a ROOT MOUNT ERROR: If you have invalid mount, reboot, and first try i think that i've missed a device in my config file, can you help me with this From the boot prompt you should be able to 'boot kernel.old' and run your old kernel until you figure it out. Good Luck -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kernel panic
On 11/12/2010 18:28, mezgani ali wrote: Can you tell me on which module depend usbbus and uhub ? On Fri, Nov 12, 2010 at 11:20 PM, jhell jh...@dataix.net wrote: On 11/12/2010 16:41, mezgani ali wrote: Hello, I compiled a custom kernel, and i got this error message : Root mount waiting for: usbbus3 uhub3: 8ports with 8 removable, self powered Trying to mount root from ufs:/dev/ad0s1a ROOT MOUNT ERROR: If you have invalid mount, reboot, and first try i think that i've missed a device in my config file, can you help me with this From the boot prompt you should be able to 'boot kernel.old' and run your old kernel until you figure it out. Good Luck -- jhell,v da, umass, scbus... There in the manual pages. -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On 10/07/2010 01:47, Devin Teske wrote: On Oct 6, 2010, at 9:49 PM, jhell wrote: On 10/06/2010 23:29, Devin Teske wrote: I see no real advantage If you had to administer thousands of FreeBSD systems, you would. Normally I have found large scale (1000's) of Unix like systems benefiting from the use of cfengine that is available via ports(7) and the use of other such software as Nagios, MUNIN for example that allow you to achieve quick deployment and monitoring of production systems. Not that this is a real comfortable solution to this either but the values contained throughout FreeBSD systems are also available via bsnmpd(1). This script is obviously targeted to those for which are mentioned in the header... system administrators, power-users, and developers. With that noted what advantage does this script bring compared to a script like service(8) that is already in the base system? service(8) clearly doesn't do what this script does. The values that associate to an executable rc.d script are but only a fraction of what rc.conf(5) is used for. See `/etc/defaults/rc.conf' for all possible values. I am well aware of its use and the values it contains for a majority of the FreeBSD releases, dating back to 4.2 ;) Before that time it was mostly Linux. How much time does a end user spend enabling/disabling services for a system? In our environment? A script like this empowers support personnel and engineers with the ability to perform a generalized query on thousands of machines simultaneously and collate the results back into a paging application (such as less(1) or more(1)), finding possible misconfigurations, problems, or other issues that arise by human error, script error, or legacy options languishing from an upgrade process. Further, with the ability to set options, it makes remediating problems quite easy. Alright, understandable. Large scale environments don't really fit into the PAGER area but I am following you. How much of a difference in time would this make to the end user as per say just having to echo a variable into an rc.conf? That's a sloppy way to manage production equipment/environments. Remember, there is a very few examples of your script to go on for usage and really not much real example usage scenarios that at least I can relate to by giving the script a quick look-over without getting really deep into it (yet). This is why the probing questions are coming up and that will at least help me if not others build a scenario at which your script can be looked at in possibly a more correct manner rather than passing judgment. If this would be put in place into the base system where would it be and who would maintain it ? It would likely be placed in the same directory as sysctl(8) (/sbin/sysrc). I would maintain it. Is it feasible to expect an end user to read rc.conf(5) services(8) while also consuming knowledge of etc/defaults/rc.conf boot(8) as well sysctl.conf(5) and loader.conf(5). A friend of mine and I just installed 8.1-RELEASE-p1 onto his laptop. We had to go through all those man-pages and more to get everything good with the wpa_supplicant_* options. We didn't have to go to google, bing, wolfram alpha, barnes noble, or any place... all the answers for setting up his laptop using 802.11g tied to a WAP w/ WPA2. But what does that have to do with the price of bread in China? Well unless those bread factories machines are powered by FreeBSD, I hope not much. ;) This script helps system administrators, power-users, and developers. It's designed to make the task of performing non-interactive edits to rc.conf(5) not only easier, but cleaner. The files are left fully in-tact by the script, which is the important part to note. It's not going to sloppily keep tacking on new values for the same directive if the script is called 1,000 times over. This enables such things as being called from cron on a regular basis even. Also you search for grep and awk in your script. No. I check for the presence of them with $PATH expansion. The have() function is a one-line function that remaps the `type' shell built-in to have no output, yet still return the error status (or lack thereof). If you read the sh(1) manual, you'll see that the `type' built-in can be passed a shell keyword, a shell function, or failing that, it will find the executable via $PATH expansion, and failing that will return error status. The have() function that I have defined in my script allows me to do this: if have grep; then # use grep else # use case with glob(7) pattern matching fi If this were to be in base, then utilities like this would not need to be searched for as base utilities are generally static to where they live in the file-system already... /usr/bin/grep /usr/bin/awk for example. I do not think it makes much sense for a base utility to search outside of its
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On 10/06/2010 23:29, Devin Teske wrote: I am not saying this to sound like I am shooting down this script but from the looks of it, I see no real advantage over the way a FreeBSD system is configured already. You could probably point these out though. With that noted what advantage does this script bring compared to a script like service(8) that is already in the base system? How much time does a end user spend enabling/disabling services for a system? How much of a difference in time would this make to the end user as per say just having to echo a variable into an rc.conf? If this would be put in place into the base system where would it be and who would maintain it ? Is it feasible to expect an end user to read rc.conf(5) services(8) while also consuming knowledge of etc/defaults/rc.conf boot(8) as well sysctl.conf(5) and loader.conf(5). Also you search for grep and awk in your script. If this were to be in base, then utilities like this would not need to be searched for as base utilities are generally static to where they live in the file-system already... /usr/bin/grep /usr/bin/awk for example. I do not think it makes much sense for a base utility to search outside of its world for a executable especially for grep(1) and awk(1). Call these directly and let the end user modify their PATH as to where the location of these would actually be called from rather than adding extra complicity. - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. Due to this disclaimer I am not sure that even the implicit BSD license can override this. Though there is a thin gray line here, it might be suitable to remove this from future email unless you are specifically addressing something to a specific person. Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: csup or svn
Just as much as top-posting I would say ;) On 09/27/2010 00:13, Aryeh Friedman wrote: Isn't that a step backwards? On Sun, Sep 26, 2010 at 11:55 PM, Greg Lewis gle...@eyesbeyond.com wrote: On Sun, Sep 26, 2010 at 11:34:34PM -0400, jhell wrote: On 09/26/2010 22:47, Aryeh Friedman wrote: I currently use: csup -h cvsup9.us.freebsd.org /usr/share/examples/cvsup/cvs-supfile and when I just ran it I got: Append to CVSROOT-src/access Edit CVSROOT-src/access,v Segmentation fault (core dumped) (8.1-STABLE #0) Should I be using SVN instead and if so what is the repo URL I need to use? You can safely remove that file and continue to do what you do... or Yes you can use SVN ports/devel/subversion-freebsd Or you can use cvsup (it doesn't segfault on that file). -- Greg Lewis Email : gle...@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : gle...@freebsd.org -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: pf
This is more for questions@ or pf@
On 09/26/2010 11:43, Samuel Martín Moro wrote:
On Sun, Sep 26, 2010 at 3:34 PM, Michael Powell nightre...@hotmail.comwrote:
Samuel Martín Moro wrote:
Hello,
I'm trying to set up pf on my soon-to-be new gateway (8.1-RELEASE amd64).
I used the sample configuration file available on
calomelhttps://calomel.org/pf_config.html
After a few tests, it appears that the gate has fully access to the
internet, but I can't open connections from clients to distant servers
(web, ssh, ...).
Checking pflog log file, I can't see anything about those timeouts, even
if I added the log directive in every block/pass command.
Everything else seems to work, I can talk with my DNS from the internet,
ssh redirections to another pc also seems to works.
I just can't access the Internet from a client of my network...
For debugging, I commented out the options and the 'block all in/out'
directives.
Here's my config file http://pastebin.com/Nim2zBCx
Is there someone understanding what I'm doing wrong?
The firewall ruleset is a trifle overly complex for a quick glance; study
and analysis would take some doing. However, if you can reach the internet
from the firewall box and other client computers behind your NAT can't
(which is what it sounds like you're describing) it may be just that you
are
missing gateway_enable=YES in your /etc/rc.conf.
Turning this ON makes your firewall box into a router. The status of this
can be checked with: sysctl net.inet.ip.forwarding - a 0 means no
gateway
and a 1 means gateway.
-Mike
___
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
freebsd-questions-unsubscr...@freebsd.org
the gateway is already enabled (and forwarding is correctly set)
whatever, I had to do quick, I started again
I think the missing thing on my old conf was the 'scrub' (at least)
I made a more simple configuration, as following:
ext_if=bge0
int_if=bge1
localnet = $int_if:network
emma=10.242.42.200
alpha=10.42.42.42
delta=10.42.42.44
set skip on lo0
scrub in on $ext_if all fragment reassemble
#INTERNETZ
nat on $ext_if from $localnet to any - ($ext_if)
#EMMA
rdr on $ext_if inet proto tcp from any to ($ext_if) port 1101 -
$emma port 22
rdr on $ext_if inet proto tcp from any to ($ext_if) port 307 -
$emma port 80
#WHAT.CD
rdr on $ext_if inet proto tcp from any to ($ext_if) port 1666 -
$alpha port 1666
#REMOTE ADM
rdr on $ext_if inet proto tcp from any to ($ext_if) port 1667 -
$delta port 22
rdr on $ext_if inet proto tcp from any to ($ext_if) port 1668 -
$alpha port 22
pass in log on $ext_if inet proto tcp from any to $ext_if port 22
pass in log on $ext_if inet proto tcp from any to $ext_if port 53
pass in log on $ext_if inet proto udp from any to $ext_if port 53
pass in log on $ext_if inet proto tcp from any to $ext_if port 1664
pass in log on $int_if inet proto tcp from any to any
pass in log on $int_if inet proto udp from any to any
block in log on $ext_if inet proto icmp from any to $ext_if
it's basically working
i'll stuff it when I'll have time.
Samuel Martín Moro
{EPITECH.} tek5
--
jhell,v
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: csup or svn
On 09/26/2010 22:47, Aryeh Friedman wrote: I currently use: csup -h cvsup9.us.freebsd.org /usr/share/examples/cvsup/cvs-supfile and when I just ran it I got: Append to CVSROOT-src/access Edit CVSROOT-src/access,v Segmentation fault (core dumped) (8.1-STABLE #0) Should I be using SVN instead and if so what is the repo URL I need to use? You can safely remove that file and continue to do what you do... or Yes you can use SVN ports/devel/subversion-freebsd Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to disallow logout
On 09/11/2010 05:07, Peter Pentchev wrote:
...but, of course, that's only until people learn that they can
bypass this by something like 'kill -FPE $$'.
Have you tried that ?
If the person/developer is looking into it that far where they need to
subvert the logout process then there is probably a pretty good reason
for doing so and would be expected that they bring it to the admins
attention or file a PR.
There is only just so much you can do before you start to modify the
code in the shell itself so the user cant execute another shell upon
login and kill their shell before other scripts run on logout.
Firstly this just sounds like a case where the admin needs to provide a
equally sound and safe way of making sure everything is cleaned up on
logout and is offering a global way of doing it so the developer will
not forget.
trap 'echo Sorry FPE not allowed. ;)' FPE
( kill -l ) will list the rest of the signals you can trap too.
And you can get pretty evil with this. But for the short term.
for sig in `jot 31 1`; do
trap 'echo WARN:$$ Please use ^D or logout(1) instead.' ${sig}
done
Of course not all of those signals will cause a logout to happen but
have fun with it.
Regards,
--
jhell,v
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to disallow logout
On 09/11/2010 07:13, Aryeh Friedman wrote: On Sat, Sep 11, 2010 at 7:07 AM, Aryeh Friedman aryeh.fried...@gmail.com wrote: Firstly this just sounds like a case where the admin needs to provide a equally sound and safe way of making sure everything is cleaned up on logout and is offering a global way of doing it so the developer will not forget. In this case the admin and developer are the same person... namely at the clients request I am the only person allowed to work on the project and I just want to make it so I can't accidently do something like control-d or something like that and leave a plain text version of a project that has a very strict NDA laying around (liquidated damages of $250k)... the scenrio is we a are a team (each one of us is in diff city) of freelance CS people and all use the same server for all our development to make cooperation possible when needed (not in this case) have centralized backups, etc. and as mentioned on this one project the client has forced me to sign a NDA saying I can't even show the code to the other team members without the client's permission and thus am storing the repo using security/fuse-encfs, but since the version control system (devel/aegis) requires creating a development directory that is not encrypted I want to force/remind myself to checkin what ever I was working into the encrypted repo when I go home (it is a home office ;-)) at night or out to lunch Forgot to mention all these percautions are to make the client comfortable with letting me take advanatage of the server's development enviroment instead of spending almost a week configuring the same env on my desktop machine... namely I trust the other team members to not look at the code even if it was not encrypted. In that case would it make sense to just use tmpfs or some other destructive file-system when it gets unmounted. Maybe one-time encryption offered by geli(8) on a mdconfig(8) swap-file for just the source that you checkout. Implement it using amd(8). Don't know if this is a possible scenario but gives you a little more to consider. Regards good luck, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to disallow logout
On 09/09/2010 23:27, Aryeh Friedman wrote: I have a directory that must not exist on logout and rm -rf is not sufficent to do it because the contents need to be processed by our version control system. The real life scenario is our version control system stores the repo for a given project encrypted but for techinical reasons it needs to keep the checkouted files in plain text (they are all in the same dir) and I want to *NEVER* have the plain text checkouted files in my dir when I logout, *BUT* instead of just deleting it I need to check them in... so how do I make my .logout so if the file exists it will not exit and give a error saying that dir is still there? (minor but unimportant side effect of the version control system is the dir will have a different name everytime it is made but always the same prefix) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org trap '/path/to/your_wrapper_script.HERE' 2 Should execute the contents of that script on every logout. Whether that script is a line by line action or a fully qualified script with functions to call different actions are up to you. Good luck, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to disallow logout
On 09/10/2010 22:21, jhell wrote: On 09/09/2010 23:27, Aryeh Friedman wrote: I have a directory that must not exist on logout and rm -rf is not sufficent to do it because the contents need to be processed by our version control system. The real life scenario is our version control system stores the repo for a given project encrypted but for techinical reasons it needs to keep the checkouted files in plain text (they are all in the same dir) and I want to *NEVER* have the plain text checkouted files in my dir when I logout, *BUT* instead of just deleting it I need to check them in... so how do I make my .logout so if the file exists it will not exit and give a error saying that dir is still there? (minor but unimportant side effect of the version control system is the dir will have a different name everytime it is made but always the same prefix) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org trap '/path/to/your_wrapper_script.HERE' 2 This should be: trap '/path/to/script' EXIT Should execute the contents of that script on every logout. Whether that script is a line by line action or a fully qualified script with functions to call different actions are up to you. Good luck, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: System freezes unexpectly
On 08/29/2010 21:39, Davide Italiano wrote: Firefox 3.6.4. Lastest from ports, compiled now. FYI: firefox-3.6.8,1 is the latest in ports. -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tiny patch to prevent head from closing pipes
On 08/28/2010 12:01, Alexander Best wrote: On Sat Aug 28 10, Anonymous wrote: Alexander Best arun...@freebsd.org writes: hi there, i just had subversion complain about a broken pipe while piping its output through awk straight to head [1]. i decided to add a switch to head which will tell it to never close a pipe unless the input has stopped [2]. You can do same with sh(1), e.g. $ svn log | (IFS=; while read li; do [ $((i+=1)) -le 10 ] echo $li; done) versus $ svn log | (IFS=; while read li [ $((i+=1)) -le 10 ]; do echo $li; done) ... svn: Write error: Broken pipe But I think subversion should there's probably a much more efficient way of discarding the input without closing the pipe unless the input ceased. it's just a 5 minute hack in order to see if people find the idea useful or not. ;) Can you give an example of usefulness that does not involve subversion? no, but this should be valid for all applications which return an error if the pipe gets closed by the receiving end. of course it's possible to implement the features to head i added in form of a sh(1) script. i understand that your point is, that there is already a way of keeping the pipe open and that the unix philosophy states that no two programs should share the same functionality. on the other hand you don't really need head and tail at all then, because their functionality could also be implemented in form of a script. ;) i hope you get my point. cheers. alex No offense but patching this would be honoring bad scripting and encouraging such things to happen more often. If you catch my drift. Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS arc_reclaim_needed: better cooperation with pagedaemon
On 08/23/2010 03:28, Artem Belevich wrote: Can anyone test the patch on a system with mix of UFS/ZFS filesystems and see if the change mitigates or solves the issue with inactive memory excessively backpressuring ARC. I have a system currently patched up to ZFSv15 and mm@'s metaslab patch running that I can test this on. Throw me a patch and some specific tests and I can have the results back to you in the next 2 days. Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS arc_reclaim_needed: better cooperation with pagedaemon
On 08/23/2010 16:42, jhell wrote: On 08/23/2010 03:28, Artem Belevich wrote: Can anyone test the patch on a system with mix of UFS/ZFS filesystems and see if the change mitigates or solves the issue with inactive memory excessively backpressuring ARC. I have a system currently patched up to ZFSv15 and mm@'s metaslab patch running that I can test this on. Throw me a patch and some specific tests and I can have the results back to you in the next 2 days. Forget the patch 1 line change I can hand type that in. As for specific tests, let me know... -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS arc_reclaim_needed: better cooperation with pagedaemon
On 08/23/2010 22:10, Artem Belevich wrote: First prepare the data. * You'll need some files totalling around the amount of physical memory on your box. Multiple copies of /usr/src should do the trick. * Place one copy on UFS filesystem and another on ZFS Experiment #1: * Prime ARC by tarring dataset on ZFS into /dev/null. * Now tar both datasets in parallel with output to /dev/null Previously you would end up with ARC size shrinking down to arc_min. What I hope to see after the patch is that inactive memory and ARC reach some sort of equilibrium with neither monopolizing all available memory. #Experiment #2: If equilibrium is reached, try running some application that would allocate and use about 1/2 of your physical memory. Something like that perl one-liner used to cause memory shortage, only a bit less drastic. perl -e '$x=xx1_000_000_000'; # this should allocate about 2GB. Tune the number to suit your system. Again, in the past ARC would be the one feeing up the memory. Let's see if inactive list gives up some, too. Alright I should be able to have something together with the output of this by the 25th with my current workload being the ultimate determining factor. PBS, Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Support for WD Advanced Format disks
On 08/10/2010 13:44, Dag-Erling Smørgrav wrote: Right now, I have two requests. The first is that people who have Advanced Format disks run a program I wrote that measures the performance of aligned and misaligned writes of different sizes. % svn co http://svn.freebsd.org/base/user/des/phybs % cd phybs % make % ./phybs -w /dev/adN DES, On stable/8 this is needed to build. Seems the need for linking against libutil came in revision r211233. Index: Makefile === --- Makefile(revision 211244) +++ Makefile(working copy) @@ -4,5 +4,6 @@ CSTD ?= c99 WARNS ?= 6 MAN = # none +LDFLAGS += -lutil .include bsd.prog.mk Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Improvement for Distributed Audit Project
On 08/09/2010 13:24, Janne Snabb wrote:
On Thu, 29 Jul 2010, Sergio Ligregni wrote:
/*
* We have these posibilities, only the first one is allowed
* 20100619223115.20100619223131 20100619223131.not_terminated
* current
*/
if (strlen(path) == 29 path[14] == '.' isdigit(path[15])) {
/* XXX To improve this checking later */
return 1;
}
Please note that the file names have an addiitional suffix in case
host is defined in /etc/security/audit_control.
Also note that auditd(8) complains to syslog that 'host:' is not set
correctly in audit_control(5) currently.
This may serve as a warning but it gets on your nerves after a while
when you look at it like a error when you first see it. Since it deals
with the audit system first glance of the warning sends error alerts off
in your head.
messages.0:Jun 4 19:47:15 disbatch auditd[1666]: audit_control(5) may
be missing 'host:' field
Is there some way that this could be silenced without actually adding
'host:' to audit_control(5) ?
Maybe a possibility to just add 'host:localhost' to the default
configuration of audit_control(5) ?
If localhost would be an option and logging audits to a remote machine
comes into play then would it be wise to ignore distribution of
localhost from the receiving machine ?
Regards,
--
jhell,v
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[DTRACE] ctfconvert .bss data: Invalid section descriptor +
Through 3 recent ``buildkernel'' runs I have logged the following. The
build logs are available to those with interest.
I have tested this with three variations to the environment i.e.
make.conf, src.conf, make -j{N}, a vanilla build. The errors come up
the same way but with a variation of the lines in the log file where the
errors appear.
I still have the tar'd object directory for the last vanilla build that
was performed.
Though these errors are prominent in the log I don't believe it has a
negative impact other than not being traceable by dtrace. I have not
observed any other impact that this could have so I decided to report
what I have here for someone else to decide on the outcome.
Summary of errors in the logs:
ctfconvert -L VERSION -g kern_ktr.o
kern_ktr.c: kern_ktr.o: Cannot get sect .bss data: Invalid section
descriptor
ctfconvert -L VERSION -g tcp_debug.o
tcp_debug.c: tcp_debug.o: Cannot get sect .bss data: Invalid section
descriptor
ctfconvert -L VERSION -g clnt_rc.o
ctfconvert -L VERSION -g ffs_tables.o
ctfconvert -L VERSION -g ufs_gjournal.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION -g local_apic.o
local_apic.c: local_apic.o: Cannot get sect .bss data: Invalid section
descriptor
ctfconvert -L VERSION msp34xx.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
dtrace.c: dtrace.o: Cannot get sect .bss data: Invalid section descriptor
ctfconvert -L VERSION if_ed_3c503.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION if_ed_hpp.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION if_ed_sic.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION mfi_debug.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ctfconvert -L VERSION ufs_gjournal.o
ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
Regards,
--
jhell,v
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [DTRACE] ctfconvert .bss data: Invalid section descriptor +
I should probably note that this is on stable/8 i386 r210115. And that this was before the 210145:210147 commits. Regards, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [DTRACE] ctfconvert .bss data: Invalid section descriptor +
On 07/16/2010 00:31, Alexander Kabaev wrote: On Thu, 15 Jul 2010 20:02:01 -0400 jhell jh...@dataix.net wrote: I should probably note that this is on stable/8 i386 r210115. And that this was before the 210145:210147 commits. This is a message from ctfconvert bogusly trying to read non-existent data from .bss. I have fix for this which I forwarded to our libelf author. The bug if harmless otherwise. Alright, thank you for confirming this. I thought this was the case but did not want to make any assumptions as to exactly what it was caused by even though the error that was popping up looked like ctfconvert's fault. Thanks again, -- jhell,v ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: registration of optional kernel features via sysctl: a question to the community
On 06/09/2010 04:14, Ilya Bakulin wrote: Hi hackers! While discussing my project's implementation details with my mentor, Alexander Leidinger, we've found that one of the ideas needs to be discussed with community, to find out possible use cases. That is, if it should be possible to spoof non-existing features. For example, if currently running kernel doesn't support FreeBSD 5.0 compat layer, kern.features.compat_freebsd5 will be absent when querying features list. The question is -- are there any cases when we want kern.features.compat_freebsd5 be present? If some feature is not in kernel, then presenting its existence to the userland is useless and may be even harmful, if, for example, some application relies on this feature. Or there are some scenarios where such cheat is useful? I can not think of any viable reason why one would want to spoof this when it is not available. To have this be present and set to a value of '0' would make sense for telling end-user program that its not available. Since a generic kernel is already built with the compatN layers that it supports I believe it would be best to look at __FreeBSD_version which should be kern.osreldate to see if that layer of compatibility is available at all and then leave it up to the end-user to enable it if they have built their own private kernel. Another thought that had come to mind was to make that sysctl an array of values for the layers of compatN that exist in the kernel. 1). Address [0] of the array is set to 1 if any compatN is available. 2). Further corresponding addresses 1 - N would correspond to _FREEBSD1 to FreeBSDN. This is why COMPAT_FREEBSD32 is bad! 3). If a compat version becomes unsupported set its array value to null. This would allow someone to be able to check against address [0] which should always exist and discontinue further checks to see what versions are available. Although it suggests subverting actually doing the work on the software writers part and checking against __FreeBSD_version to see what versions are available in a 'GENERIC' kernel. Just a thought but I would rather see an array of values than 3 - 4 separate sysctls. Kind regards happy hacking, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GSoC: registration of optional kernel features via sysctl: a question to the community
On 06/09/2010 09:25, Kostik Belousov wrote:
On Wed, Jun 09, 2010 at 09:13:56AM -0400, jhell wrote:
On 06/09/2010 04:14, Ilya Bakulin wrote:
Hi hackers!
While discussing my project's implementation details with my mentor,
Alexander Leidinger, we've found that one of the ideas needs to be
discussed with community,
to find out possible use cases.
That is, if it should be possible to spoof non-existing features. For
example, if currently running kernel doesn't support FreeBSD 5.0 compat
layer, kern.features.compat_freebsd5 will be absent when querying
features list. The question is -- are there any cases when we want
kern.features.compat_freebsd5 be present? If some feature is not in
kernel, then presenting its existence to the userland is useless
and may be even harmful, if, for example, some application relies on this
feature.
Or there are some scenarios where such cheat is useful?
I can not think of any viable reason why one would want to spoof this
when it is not available.
Many ports are doing wrong thing there, checking for run-time features at
the build-time, turning on/off some functionality depending on its
presence on the build host.
That would lead me to believe that the elimination of this sysctl would
be better suited to solve the outcome of cases like this.
And leads me to believe that it still rests on the end-user to tell
whether or not they have that compatibility layer compiled in.
Like I stated more towards the end of my last message I believe
checking __FreeBSD_version should suffice and leave the final result up
to the end-user as GENERIC will have the COMPAT_FREEBSD{N} layers
compiled in that it needs or can support or are recommended.
Being that this is a broad scenario and many different compilations of
kernels could be used I still do not see a need to test for every one of
them if an adequate means already exists. GENERIC in any case should be
the kernel that is depended on and testing against __FreeBSD_version for
what COMPAT versions are supported.
Regards,
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Aurora Scheduler
On 06/05/2010 18:32, Mohammed Farrag wrote: Hi group, I am working on developing a new freebsd kernel theme for embedded. I was searching for the best scheduler. I think the best one is Aurora Scheduler developed by NASA. I found that it can be included in the configuration file in the freebsd but the problem was Is it available for use by users? the other one was where I can find its technique. Good luck, Mohammed Farrag ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org SCHED_ULE or SCHED_4BSD Thats your two options with ULE being the default in recent 8.0+ systems. Use ( sysctl kern.sched.name ) to determine which one you are using. Unless I misunderstood the intention of your message I would say that you are a bit confused about what the Aurora Scheduler is/means as compared to what FreeBSD uses as sched_ule(4) or sched_4bsd(4). Regards, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Fwd: Re: Aurora Scheduler
Original Message Subject: Re: Aurora Scheduler Date: Sat, 05 Jun 2010 20:15:49 -0400 From: jhell jh...@dataix.net To: Mohammed Farrag eng.mu...@gmail.com On 06/05/2010 19:23, Mohammed Farrag wrote: Hi all, thanx for ur reply. First Aurora shows the schedule in a series of graphical displays that allow the user to see the resource allocations and the temporal relationships among the elements. This display also allows the user to edit the schedule directly and easily. Aurora focuses on resource requirements and temporal scheduling in combination. see that : http://www.stottlerhenke.com/products/aurora/?gclid=CNn85aj0iaICFVKX2Aodam_wVQ#challenge and http://sbir.nasa.gov/SBIR/successes/ss/10-020text.html it is used in very large projects and used to manage resources. I was asking about the algorithm it use in scheduling process and we can apply it to FreeBSD processes for scheduling. Second, I know that it is not available in native FreeBSD so I intend to build it manually but I just need the algorithm it use to schedule processes based on resources and complex constraints. Good Luck, Mohammed Farrag I'm afraid that you are confused about what the scheduler in the FreeBSD kernel does and what the Aurora Scheduler is. They are not relational to one another in any such way. http://sbir.nasa.gov/SBIR/successes/ss/10-020text.html There is not a similiar scheduling program in FreeBSD but there is Evolution, Kontact and other such things to manage your time. Good Luck -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Exposing Zone Sleeps
On 05/26/2010 17:31, jhell wrote: On 05/26/2010 13:29, Sean Bruno wrote: On Tue, 2010-05-25 at 07:47 -0700, Sean Bruno wrote: Hi Sean, Nice work on this. I applied this to stable/8 r208530 and I am in the process of compiling the kernel right now. Everything else has built runs as expected i386. Attached is the adjusted patch which was one modification to the line number for uz_sleeps in sys/vm/uma_int.h. 8 files changed, 106 insertions(+), 7 deletions(-) For those wishing to apply this patch and test for them self: cd /usr/src patch /path/to/sleep_stat_stable8_r208530.diff cd /usr/src/include make obj make depend make includes make install cd /usr/src/lib/libmemstat make obj make depend make includes make install cd /usr/src/usr.bin/vmstat make obj make depend make install cd /usr/src make kernel KERNCONF=YOUR_KERN_CONF reboot Can't wait to see some results from this I will report back with either negative results of the build run or positive results from the stats collected. If there is anything needed feel free to let me know and I will do what is possible ASAP. Thanks again, - -- jhell Excellent. Please check the output of vmstat -z and the appropriate sysctl. I changed the display a bit to keep it from wrapping on a standard terminal. Sean P.S. My intention it to MFC this to all releases. I do have a concern related to the removal of an #ifdef DDB in this patch. Any comments? Sean This was in your original patch sent to the list. I questioned it too but as far as testing it goes it has caused no harm that I can see here but I will add those back in along with the improvements from Garrett, then regenerate the patch and send it back to the list. Regards, Following up on this, it has been ~ 1 - 2 weeks with this patch on 4 machines I have had in question and have not noticed any negative effects or gains from what this patch provides. On a stable/8 i386 system there were absolutely no SLEEP stat bumps recorded at all. On a second note one negative impact that I had observed is the negative ability to upgrade a stable/7 system to a stable/8 system with this patch applied due to mismatched symbols or other related symptoms that would suggest that the patch would also have to be applied to the older system and compiled before the upgrade. This all had more to do with 'vm_uma_zone' being undeclared. Although this is a nice feature I do not see any benefits for applying it to a stable/7 or stable/8 systems as those are already clean. But applying this to HEAD for debugging of sleep issues that may creep into the code would be useful as a type of alert until the next release at which it should be turned off and ejected from the tree unless it was separated into the src/tools/tools directory as a debugging tool. With all luck kind regards, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Exposing Zone Sleeps
On 05/26/2010 13:29, Sean Bruno wrote: On Tue, 2010-05-25 at 07:47 -0700, Sean Bruno wrote: Hi Sean, Nice work on this. I applied this to stable/8 r208530 and I am in the process of compiling the kernel right now. Everything else has built runs as expected i386. Attached is the adjusted patch which was one modification to the line number for uz_sleeps in sys/vm/uma_int.h. 8 files changed, 106 insertions(+), 7 deletions(-) For those wishing to apply this patch and test for them self: cd /usr/src patch /path/to/sleep_stat_stable8_r208530.diff cd /usr/src/include make obj make depend make includes make install cd /usr/src/lib/libmemstat make obj make depend make includes make install cd /usr/src/usr.bin/vmstat make obj make depend make install cd /usr/src make kernel KERNCONF=YOUR_KERN_CONF reboot Can't wait to see some results from this I will report back with either negative results of the build run or positive results from the stats collected. If there is anything needed feel free to let me know and I will do what is possible ASAP. Thanks again, - -- jhell Excellent. Please check the output of vmstat -z and the appropriate sysctl. I changed the display a bit to keep it from wrapping on a standard terminal. Sean P.S. My intention it to MFC this to all releases. I do have a concern related to the removal of an #ifdef DDB in this patch. Any comments? Sean This was in your original patch sent to the list. I questioned it too but as far as testing it goes it has caused no harm that I can see here but I will add those back in along with the improvements from Garrett, then regenerate the patch and send it back to the list. Regards, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Exposing Zone Sleeps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/26/2010 14:58, Sean Bruno wrote:
On Wed, 2010-05-26 at 11:52 -0700, Garrett Cooper wrote:
This patch instead pardon the early.post but there was a problem with
the last patch that I attached for stable/8 r208530 with arguments 10
11 to function sysctl_vm_zone where it wanted a long unsigned integer
rather than u_int64_t.
This patch satisfies that. Whether its correct is left to the reader but
compiles cleanly runs smoothly.
I know this seems trivial, but could you change:
+ printf(%-20s %6s %6s %8s %8s %8s %4s %4s\n\n, ITEM, SIZE,
+ LIMIT, USED, FREE, REQ, FAIL, SLEEP);
to
+ printf(%-20s %6s %6s %8s %8s %8s %4s %4s\n\n, ITEM, SIZE,
+ LIMIT, USED, FREE, REQS, FAIL, SLEEP);
that way the plural nature of requests is more straightforward and
understood.
Also, do all of the fields _really_ need to have a field width? Seems
like overkill to me...
Oh, and the field width for the last item is wrong; SLEEP will be
truncated to SLEE.
Thanks,
-Garrett
I hate this type of column implementation. Any ideas on a more useful
implementation?
also, I'm missing an email in this thread somehow. I didn't see the
second version of the REL-8 patch.
Sean
Attached is the diff against vmstat.c only *just* to view the
differences. This is also in the sleep_stat_stable8-r208580.diff so no
need to patch twice.
Also attached is the patch for sleep stat on stable/8 revised. against
r208580:
Changes:
* Added back the #ifdef DDB
* vmstat(1) displays all columns in a 80 column display cleanly.
Comments suggestions ?
I am a little bit shaky about putting the last column so close to the
end of the terminal but that may just be my own personal worries but for
now every field should have enough room to grow as far as I can verify
on my own equipment. Test this out and let me know what you think, if it
wraps or not and whether you think there is enough space for the numbers
to grow in the current layout of the columns.
Thanks again regards,
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJL/cGqAAoJEJBXh4mJ2FR+oo4IAJWt9sOEhnlmZOG+8Ehf7SKt
QX5ZxBDHz196FR5zOW1p4xjfkGX5ZVD0WytHS7JyTxTiMxkvzELfFpbzfGFtp1U8
Hgtv76gCZnZOEdOTCdtjknJmJNw6FC9FMAXLv5f4tzBj8HNo5sfg0x9wBmEiUfI0
8WO9f83n62lKV5SRyx+jRM/FeAZsNz9zAT0+Z8UmYUDSy+u6jFLYbWD71TzwLMKd
8+Ba/5qsnTTFVfqZOG3lRPcOCdj1QBicRzL+hyKfmNFT1IN8Xek+BhE9sDiOmqK2
0dt87kaDBV5reAeQ1P0Cqvgl7m1JGWg0bJL+c5Z7O2MpcosOxqbfTji1lHQiVZo=
=uA4o
-END PGP SIGNATURE-
Index: vmstat.c
===
--- vmstat.c (revision 208580)
+++ vmstat.c (working copy)
@@ -1286,16 +1286,17 @@
memstat_strerror(error));
}
}
- printf(%-20s %8s %8s %8s %8s %8s %8s\n\n, ITEM, SIZE,
- LIMIT, USED, FREE, REQUESTS, FAILURES);
+ printf(%-20s %+6s %+8s %+8s %+6s %+10s %+8s %+6s\n\n, ITEM, SIZE,
+ LIMIT, USED, FREE, REQS, FAIL, SLEEP);
for (mtp = memstat_mtl_first(mtlp); mtp != NULL;
mtp = memstat_mtl_next(mtp)) {
strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME);
strcat(name, :);
- printf(%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n, name,
+ printf(%-20s %+6llu,%+8llu,%+8llu,%+6llu,%+10llu,%+8llu,%+6llu\n,name,
memstat_get_size(mtp), memstat_get_countlimit(mtp),
memstat_get_count(mtp), memstat_get_free(mtp),
- memstat_get_numallocs(mtp), memstat_get_failures(mtp));
+ memstat_get_numallocs(mtp), memstat_get_failures(mtp),
+ memstat_get_sleeps(mtp));
}
memstat_mtl_free(mtlp);
printf(\n);
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 208580)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -1286,16 +1286,17 @@
memstat_strerror(error));
}
}
- printf(%-20s %8s %8s %8s %8s %8s %8s\n\n, ITEM, SIZE,
- LIMIT, USED, FREE, REQUESTS, FAILURES);
+ printf(%-20s %+6s %+8s %+8s %+6s %+10s %+8s %+6s\n\n, ITEM, SIZE,
+ LIMIT, USED, FREE, REQS, FAIL, SLEEP);
for (mtp = memstat_mtl_first(mtlp); mtp != NULL;
mtp = memstat_mtl_next(mtp)) {
strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME);
strcat(name, :);
- printf(%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n, name,
+ printf(%-20s %+6llu,%+8llu,%+8llu,%+6llu,%+10llu,%+8llu,%+6llu\n,name,
memstat_get_size(mtp), memstat_get_countlimit(mtp),
memstat_get_count(mtp), memstat_get_free(mtp),
- memstat_get_numallocs(mtp), memstat_get_failures(mtp));
+ memstat_get_numallocs(mtp), memstat_get_failures(mtp),
+ memstat_get_sleeps(mtp));
}
memstat_mtl_free(mtlp);
printf(\n);
Index: lib/libmemstat/memstat.h
===
--- lib/libmemstat/memstat.h (revision 208580)
+++ lib/libmemstat/memstat.h (working copy)
@@ -139,6 +139,7 @@
uint64_t memstat_get_count(const struct
Re: Exposing Zone Sleeps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/24/2010 18:26, Sean Bruno wrote:
Find attached a patch against -CURRENT.
This update exposes a counter that indicates the number of times that we
sleep when attempting to allocate a slab from the keg. In other words,
the number of times we BLOCK and wait, which is bad.
This allows differentiation between times when we failed to allocate and
it was ok and times where we were forced to sleep. The current FAIL
counter does not make this distinction.
Exposes this information via uma_zone_t-uz_sleeps.
Add a new sysctl to retrieve this information.
Enhance vmstat -z to retrieve this information.
We've found this *extremely* useful here at Yahoo in the past and would
like to commit this if it is acceptable.
Tested on 32bit and 64bit architectures on 6/7/CURRENT.
Hi Sean,
Nice work on this. I applied this to stable/8 r208530 and I am in the
process of compiling the kernel right now. Everything else has built
runs as expected i386. Attached is the adjusted patch which was one
modification to the line number for uz_sleeps in sys/vm/uma_int.h.
8 files changed, 106 insertions(+), 7 deletions(-)
For those wishing to apply this patch and test for them self:
cd /usr/src
patch /path/to/sleep_stat_stable8_r208530.diff
cd /usr/src/include
make obj make depend make includes make install
cd /usr/src/lib/libmemstat
make obj make depend make includes make install
cd /usr/src/usr.bin/vmstat
make obj make depend make install
cd /usr/src
make kernel KERNCONF=YOUR_KERN_CONF
reboot
Can't wait to see some results from this I will report back with
either negative results of the build run or positive results from the
stats collected.
If there is anything needed feel free to let me know and I will do what
is possible ASAP.
Thanks again,
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJL+9g3AAoJEJBXh4mJ2FR+1UoIAJnJ0gvQBOVjvccj2DueHedg
gk9SCeebEys2xjrqlTP3HrsaWl+zJcZoR6qJbJnSw3sIAkXbSAptaVH7xOx7o3vj
cngqEVGcq99w8NILFjCvpMJBIs7iBY0ZqRFgloIdoNdB1DNugwKNZVtvd17WUlWJ
MstE/kSGVmYVqIVARXx6ucEMrxI1wWgNOPDmI3dZWxDD/gZi5m3hvhyQt2Ub6oQu
kAagDeVIluk4fMHk5KkwQjJajciaaXLTd50FakhWcpMOH1sFd2Ks4eJRh3RI70Eo
UpgIrOJZWMFH7G9mtoYRk6hxd6Qgw+8lqoJP+P/i322wPJ4vPHciqaIOxWiERCA=
=acrJ
-END PGP SIGNATURE-
M usr.bin/vmstat/vmstat.c
M lib/libmemstat/memstat.h
M lib/libmemstat/memstat.c
M lib/libmemstat/memstat_internal.h
M lib/libmemstat/memstat_uma.c
M sys/vm/uma_int.h
M sys/vm/uma.h
M sys/vm/uma_core.c
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 208530)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -1286,16 +1286,17 @@
memstat_strerror(error));
}
}
- printf(%-20s %8s %8s %8s %8s %8s %8s\n\n, ITEM, SIZE,
- LIMIT, USED, FREE, REQUESTS, FAILURES);
+ printf(%-20s %6s %6s %8s %8s %8s %4s %4s\n\n, ITEM, SIZE,
+ LIMIT, USED, FREE, REQ, FAIL, SLEEP);
for (mtp = memstat_mtl_first(mtlp); mtp != NULL;
mtp = memstat_mtl_next(mtp)) {
strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME);
strcat(name, :);
- printf(%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n, name,
+ printf(%-20s %6llu, %6llu,%8llu,%8llu,%8llu,%4llu,%4llu\n,name,
memstat_get_size(mtp), memstat_get_countlimit(mtp),
memstat_get_count(mtp), memstat_get_free(mtp),
- memstat_get_numallocs(mtp), memstat_get_failures(mtp));
+ memstat_get_numallocs(mtp), memstat_get_failures(mtp),
+ memstat_get_sleeps(mtp));
}
memstat_mtl_free(mtlp);
printf(\n);
Index: lib/libmemstat/memstat.h
===
--- lib/libmemstat/memstat.h (revision 208530)
+++ lib/libmemstat/memstat.h (working copy)
@@ -139,6 +139,7 @@
uint64_t memstat_get_count(const struct memory_type *mtp);
uint64_t memstat_get_free(const struct memory_type *mtp);
uint64_t memstat_get_failures(const struct memory_type *mtp);
+uint64_t memstat_get_sleeps(const struct memory_type *mtp);
void *memstat_get_caller_pointer(const struct memory_type *mtp,
int index);
void memstat_set_caller_pointer(struct memory_type *mtp,
Index: lib/libmemstat/memstat.c
===
--- lib/libmemstat/memstat.c (revision 208530)
+++ lib/libmemstat/memstat.c (working copy)
@@ -188,6 +188,7 @@
mtp-mt_count = 0;
mtp-mt_free = 0;
mtp-mt_failures = 0;
+ mtp-mt_sleeps = 0;
mtp-mt_zonefree = 0;
mtp-mt_kegfree = 0;
@@ -304,6 +305,13 @@
return (mtp-mt_failures);
}
+uint64_t
+memstat_get_sleeps(const struct memory_type *mtp)
+{
+
+ return (mtp-mt_sleeps);
+}
+
void *
memstat_get_caller_pointer(const struct memory_type *mtp, int index)
{
Index: lib/libmemstat/memstat_internal.h
===
--- lib/libmemstat/memstat_internal.h
Re: Exposing Zone Sleeps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/2010 10:01, jhell wrote:
On 05/24/2010 18:26, Sean Bruno wrote:
Find attached a patch against -CURRENT.
This update exposes a counter that indicates the number of times that we
sleep when attempting to allocate a slab from the keg. In other words,
the number of times we BLOCK and wait, which is bad.
This allows differentiation between times when we failed to allocate and
it was ok and times where we were forced to sleep. The current FAIL
counter does not make this distinction.
Exposes this information via uma_zone_t-uz_sleeps.
Add a new sysctl to retrieve this information.
Enhance vmstat -z to retrieve this information.
We've found this *extremely* useful here at Yahoo in the past and would
like to commit this if it is acceptable.
Tested on 32bit and 64bit architectures on 6/7/CURRENT.
Hi Sean,
Nice work on this. I applied this to stable/8 r208530 and I am in the
process of compiling the kernel right now. Everything else has built
runs as expected i386. Attached is the adjusted patch which was one
modification to the line number for uz_sleeps in sys/vm/uma_int.h.
8 files changed, 106 insertions(+), 7 deletions(-)
For those wishing to apply this patch and test for them self:
cd /usr/src
patch /path/to/sleep_stat_stable8_r208530.diff
cd /usr/src/include
make obj make depend make includes make install
cd /usr/src/lib/libmemstat
make obj make depend make includes make install
cd /usr/src/usr.bin/vmstat
make obj make depend make install
cd /usr/src
make kernel KERNCONF=YOUR_KERN_CONF
reboot
Can't wait to see some results from this I will report back with
either negative results of the build run or positive results from the
stats collected.
If there is anything needed feel free to let me know and I will do what
is possible ASAP.
Thanks again,
This patch instead pardon the early.post but there was a problem with
the last patch that I attached for stable/8 r208530 with arguments 10
11 to function sysctl_vm_zone where it wanted a long unsigned integer
rather than u_int64_t.
This patch satisfies that. Whether its correct is left to the reader but
compiles cleanly runs smoothly.
Regards,
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJL/BZfAAoJEJBXh4mJ2FR+AqkH/2feS63nkRTGvYBNWUXMl/5t
th4JJWXF0nvN5KjcLlP79mSI06Enc3W3+EFooPZyZugOKUHhM/ex14nGYjQUzA8f
S3JPpLmF4Mqga1kiK55NQd+OiGtfn74qrRE8MeDR8ravcUpQjN3rbbZtoPYIMe0G
lX7JVXVvmKEL5YvWULEEaU7ckVCb+fAR44t1JOEmFYI7xew7bbvdEno728ZHxO8V
gt291dC+MNUqIDsj52LgEPZ4zet/CuU6MeQ7D0SJ5YUDzQ1GH8qlCJ/8jxg0c3/a
IIXEmRRH494YHMQrVsrOZgho6YRs1x1B6x2Tqm8mlAqpDDAEKETlJ2CCtXvGt5M=
=fd+F
-END PGP SIGNATURE-
M usr.bin/vmstat/vmstat.c
M lib/libmemstat/memstat.h
M lib/libmemstat/memstat.c
M lib/libmemstat/memstat_internal.h
M lib/libmemstat/memstat_uma.c
M sys/vm/uma_int.h
M sys/vm/uma.h
M sys/vm/uma_core.c
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 208530)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -1286,16 +1286,17 @@
memstat_strerror(error));
}
}
- printf(%-20s %8s %8s %8s %8s %8s %8s\n\n, ITEM, SIZE,
- LIMIT, USED, FREE, REQUESTS, FAILURES);
+ printf(%-20s %6s %6s %8s %8s %8s %4s %4s\n\n, ITEM, SIZE,
+ LIMIT, USED, FREE, REQ, FAIL, SLEEP);
for (mtp = memstat_mtl_first(mtlp); mtp != NULL;
mtp = memstat_mtl_next(mtp)) {
strlcpy(name, memstat_get_name(mtp), MEMTYPE_MAXNAME);
strcat(name, :);
- printf(%-20s %8llu, %8llu, %8llu, %8llu, %8llu, %8llu\n, name,
+ printf(%-20s %6llu, %6llu,%8llu,%8llu,%8llu,%4llu,%4llu\n,name,
memstat_get_size(mtp), memstat_get_countlimit(mtp),
memstat_get_count(mtp), memstat_get_free(mtp),
- memstat_get_numallocs(mtp), memstat_get_failures(mtp));
+ memstat_get_numallocs(mtp), memstat_get_failures(mtp),
+ memstat_get_sleeps(mtp));
}
memstat_mtl_free(mtlp);
printf(\n);
Index: lib/libmemstat/memstat.h
===
--- lib/libmemstat/memstat.h (revision 208530)
+++ lib/libmemstat/memstat.h (working copy)
@@ -139,6 +139,7 @@
uint64_t memstat_get_count(const struct memory_type *mtp);
uint64_t memstat_get_free(const struct memory_type *mtp);
uint64_t memstat_get_failures(const struct memory_type *mtp);
+uint64_t memstat_get_sleeps(const struct memory_type *mtp);
void *memstat_get_caller_pointer(const struct memory_type *mtp,
int index);
void memstat_set_caller_pointer(struct memory_type *mtp,
Index: lib/libmemstat/memstat.c
===
--- lib/libmemstat/memstat.c (revision 208530)
+++ lib/libmemstat/memstat.c (working copy)
@@ -188,6 +188,7 @@
mtp-mt_count = 0;
mtp-mt_free = 0;
mtp-mt_failures = 0;
+ mtp-mt_sleeps = 0;
mtp
Re: adding check option to md5(1) [was: md5(1) and cal(1) on -questions]
On 05/12/2010 04:01, Eitan Adler wrote:
D 2. Why doesn't md5(1) have a check option? Seems to me requiring a
D manual inspection is error-prone at best, and makes scripting
D unecessarily complicated.
Would something like the attached patch be good?
It adds a -c option for a string to check against. It prints
[failed] if the string does not match the files md5 unless in -q
mode.
It also returns 2 to indicate md5 match failure for use in scripts.
I have reviewed this patch for functionality and my final conclusion is
commit it.
Though I would like to see the same functionality that the GNU GPL'd
version of md5 has with the '-c' option and being able to check every
sum that is listed in a file against a file on disk(c), this version
brings the availability to doing the checking right from md5 and utils
from a script.
I have also edited the manual page portion of the patch to include the
'[-c string]' option in the SYNOPSIS section of the man pages. This
newly generated patch was generated from the root of the source tree.
# cd /path/to/src
# patch /path/to/patch-file
# cd /path/to/src/sbin/md5
# make obj make depend make make install
Additionally. Thanks for your work on this.
Regards,
--
jhell
Index: sbin/md5/md5.1
===
--- sbin/md5/md5.1 (revision 208194)
+++ sbin/md5/md5.1 (working copy)
@@ -8,18 +8,22 @@
.Sh SYNOPSIS
.Nm md5
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Nm sha1
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Nm sha256
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Nm rmd160
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Sh DESCRIPTION
@@ -73,6 +77,8 @@
The hexadecimal checksum of each file listed on the command line is printed
after the options are processed.
.Bl -tag -width indent
+.It Fl c Ar string
+Compare files to this md5 string
.It Fl s Ar string
Print a checksum of the given
.Ar string .
@@ -101,7 +107,8 @@
and
.Nm rmd160
utilities exit 0 on success,
-and 1 if at least one of the input files could not be read.
+1 if at least one of the input files could not be read,
+and 2 if at least one file does not have the same hash as the -c option.
.Sh SEE ALSO
.Xr cksum 1 ,
.Xr md5 3 ,
Index: sbin/md5/md5.c
===
--- sbin/md5/md5.c (revision 208194)
+++ sbin/md5/md5.c (working copy)
@@ -44,6 +44,8 @@
int qflag;
int rflag;
int sflag;
+unsigned char* checkAgainst;
+intchecksFailed;
typedef void (DIGEST_Init)(void *);
typedef void (DIGEST_Update)(void *, const unsigned char *, size_t);
@@ -138,8 +140,13 @@
digest = 0;
failed = 0;
- while ((ch = getopt(argc, argv, pqrs:tx)) != -1)
+ checkAgainst = NULL;
+ checksFailed = 0;
+ while ((ch = getopt(argc, argv, c:pqrs:tx)) != -1)
switch (ch) {
+ case 'c':
+ checkAgainst = optarg;
+ break;
case 'p':
MDFilter(Algorithm[digest], 1);
break;
@@ -173,12 +180,19 @@
failed++;
} else {
if (qflag)
- printf(%s\n, p);
+ printf(%s, p);
else if (rflag)
- printf(%s %s\n, p, *argv);
+ printf(%s %s, p, *argv);
else
- printf(%s (%s) = %s\n,
+ printf(%s (%s) = %s,
Algorithm[digest].name, *argv, p);
+ if (checkAgainst strcmp(checkAgainst,p))
+ {
+ checksFailed++;
+ if (!qflag)
+ printf(%s,[ Failed ]);
+ }
+ printf(\n);
}
} while (*++argv);
} else if (!sflag (optind == 1 || qflag || rflag))
@@ -186,6 +200,8 @@
if (failed != 0)
return (1);
+ if (checksFailed != 0)
+ return (2);
return (0);
}
@@ -198,12 +214,20 @@
size_t len = strlen(string);
char buf[HEX_DIGEST_LENGTH];
+ alg-Data(string,len,buf);
if (qflag)
- printf(%s\n, alg-Data(string, len, buf));
+ printf(%s, buf);
else if (rflag)
- printf(%s \%s\\n, alg-Data(string, len, buf), string);
+ printf(%s \%s\, buf, string);
else
- printf(%s (\%s\) = %s\n, alg-name, string,
alg-Data(string, len, buf
Re: Efficient way to determine when a child process forks or calls exec
On 05/17/2010 10:33, Dan McNulty wrote: Hi all, I have been experimenting with ptrace to determine when a child process forks or calls exec. Particularly, I have explored tracing every system call entry and exit similar to what the truss utility does, and for my case, the performance impact of tracing every system call is too great. Is there a more efficient way than tracing every system call entry and exit to determine when a child process forks, calls exec, or creates a new LWP? Thanks a lot for your help! -Dan Not sure if this is exactly what your looking for but have you looked into possibly using the audit system for tracking these things ? In its own way its really efficient and the utilities that are provided (auditreduce) you might just find a easier way to get the information your looking for. Regards, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
On 04/16/2010 05:18, krad wrote:
On 16 April 2010 09:39, David Xu davi...@freebsd.org wrote:
Jeremy Lea wrote:
Hi,
This is off topic to this list, but I dont want to subscribe to -chat
just to post there... Someone is currently running a distributed SSH
attack against one of my boxes - one attempted login for root every
minute or so for the last 48 hours. They wont get anywhere, since the
box in question has no root password, and doesn't allow root logins via
SSH anyway...
But I was wondering if there were any security researchers out there
that might be interested in the +-800 IPs I've collected from the
botnet? The resolvable hostnames mostly appear to be in Eastern Europe
and South America - I haven't spotted any that might be 'findable' to
get the botnet software.
I could switch out the machine for a honeypot in a VM or a jail, by
moving the host to a new IP, and if you can think of a way of allowing
the next login to succeed with any password, then you could try to see
what they delivered... But I don't have a lot of time to help.
Regards,
-Jeremy
Try to change SSH port to something other than default port 22,
I always did this for my machines, e.g, change them to 13579 :-)
Regards,
David Xu
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
dont allow password auth, tcp wrap it, and acl it with pf. Probably more
stuff you can do. Think onions
Not allowing password auth also means turning off PAM authentication for
logins with openssh and has the resulting effect utmp not being updated
among other things. Be sure you want to go this route.
tcpwrap it ? that is unneeded. The moment you start configuring
hosts.allow your system is going to be sending requests for ident. Its a
bad idea with all the other options that are available.
pf (GREAT IDEA!) I use the following for example on a home box to limit
the exposure to attacks.
shports=ssh
table blacklist file /etc/pf/tables/blacklist
... some other rules ...
block log quick from blacklist label Blacklisted
some more rules ...
pass in log quick proto { tcp } from any port 1024 to any port \
{ $shports } label SSH/Login:$dstport keep state (max-src-conn \
5, max-src-conn-rate 15/30 overload blacklist flush global)
pass out all label Implicit
Soon as a offender violates this they end up in the blacklist which I
run below url on every 3 hours to save to the file listed in the table
store above:
http://tinyurl.com/29y4zdh
Good luck.
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] The official logo for logo_saver?
On 04/07/2010 03:18, Dag-Erling Smørgrav wrote: Jung-uk Kim j...@freebsd.org writes: Although I really like logo_saver with Beastie, we have the official FreeBSD logo and I think it is time to say good-bye to the old logo image file. The attached file is a drop-in replacement for sys/dev/syscons/logo/logo.c. What do you think? I agree, please commit. DES How about this... Keep both rename the current logo_saver to mascot_saver instead. ? Nice work Jung-uk Kim! -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] The official logo for logo_saver?
On 04/07/2010 11:13, Freddie Cash wrote: On Tue, Apr 6, 2010 at 3:29 PM, Jung-uk Kim j...@freebsd.org wrote: Although I really like logo_saver with Beastie, we have the official FreeBSD logo and I think it is time to say good-bye to the old logo image file. The attached file is a drop-in replacement for sys/dev/syscons/logo/logo.c. What do you think? Jung-uk Kim * PS: I couldn't find a good small 256-color image from FreeBSD.org. So, I googled and found the following icon: http://kde-look.org/CONTENT/content-m1/m112422-1.png The following URL seems to be the actual web page: http://kde-look.org/content/show.php?content=112422 Please consider renaming the existing logo_saver to something like beastie_saver, to keep it around as an option. Then replace logo_saver with the new logo. Ugh! reply coming through and for some reason threading was broken for a moment and didnt see the last two replies. /ignore ;) -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: Puzzling stack trace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 26 Mar 2010 10:52, Peter Steele wrote: Are you absolutely sure the machine you ran gdb on has the exact same libc etc. as the customer's machine? I just connected to the customer's box and generated the stack trace directly on their box. It looks identical to the one I posted in my original message. Something's not right here... As stated in a earlier message. This may help get the information you need. Just more of a automated approach to compiling these. - --- Script Start --- #!/bin/sh LIBDIR=/usr/src/lib DBGLIBS=libc libelf libthr TARGETS=obj depend includes for dbglib in $DBGLIBS; do for target in $TARGETS; do make -C $LIBDIR/$dbglib $target done make -C $LIBDIR/$dbglib DEBUG_FLAGS=-g make -C $LIBDIR/$dbglib DEBUG_FLAGS=-g install done - --- Script Stop --- Good luck, - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLrNwFAAoJEJBXh4mJ2FR+rG4IAIvovWp+XxPY9YneRNZiIU4L IdblzvTz3LoRcs37EUUsNwX4PPvgmEbZ4D0lyM3ZPMxuYKhW0+rtavueSyPFLWvQ OUbmVf7AdH3OTYm7wUS8ThupkFw3N6sVxbMyR+4W1bPFilMIks5jDWXo2a8naGg2 y//5wxT+4hq47NJos2keeP2Y6AqVFVs7D5w0/TgcqUjgGco9HaTWXJN80Z+rY5PL TOLa2vZr/5/7C8n96nBbjdn5ksop3NQC4S1Uo/4Kp46YoBWivhyEQmMb7nlnrvFG m6yUZEi7TQX9QPF3zUIyrt+LlmuUHb4x1atN8sXuoDbifbJvTBN6m3unRArBkEM= =FTj8 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Compiling kernel with gcc43
On Fri, 26 Mar 2010 09:01, Jille Timmermans wrote: In Message-Id: 4bacb021.9000...@quis.cx Op 25-3-2010 18:31, Garrett Cooper schreef: -Wno-error . -Garrett I tried building world with it; but it doesn't seem to work :( [q...@istud /usr/src]$ CFLAGS=-Wno-error -Garrett make buildworld [snip] cc: unrecognized option '-Garrett' ;) -- Jille ROFL I sure hope your kidding! because cc --Jille won't work either! -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Compiling kernel with gcc43
On 03/26/2010 12:47, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Jille Timmermans ji...@quis.cx writes: I tried building world with it; but it doesn't seem to work :( [q...@istud /usr/src]$ CFLAGS=-Wno-error -Garrett make buildworld [snip] cc: unrecognized option '-Garrett' ;) ROFL I sure hope your kidding! No, he's from a country where ;) means I'm deadly serious. DES L0L -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Something rotten in ports (was Re: package building failure irritation)
On Sat, 13 Mar 2010 23:31, xorquewasp@ wrote: 'Lo, On 2010-03-13 20:40:32, jhell wrote: Not that this is a solution to your problem but it might be a possibility for you to consider, but a couple years back I dropped using make package(-recursive) and just scripted out making backup packages using something like the following. I particularly like this solution! I might just go ahead and implement this here, including the signing. Thanks. xw No Problem. Your welcome. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Something rotten in ports (was Re: package building failure irritation)
On Sat, 13 Mar 2010 02:52, xorquewasp@ wrote:
Have you tried just setting PORTSDIR and letting bsd.port.mk set the
rest of the paths with their defaults that are relative to PORTSDIR? If
that works, then we can start hunting for places that are not handling
absolute vs. relative paths correctly in bsd.port.mk.
Now, with only:
PORTSDIR=/var/ports/tree
.. in make.conf, the error is:
Creating package /var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz
Registering depends: dbus-glib-0.84 gio-fam-backend-2.22.4 gamin-0.1.10_3
glib-2.22.4 gettext-0.17_1 dbus-1.2.16_1 libxml2-2.7.6_1 libiconv-1.13.1_1
libX11-1.2.1_1,1 libxcb-1.5 libpthread-stubs-0.3_3 pcre-8.00 libXau-1.0.4
libXdmcp-1.0.2_1 xproto-7.0.15 pkg-config-0.23_1 perl-5.10.1 python26-2.6.4
gnome_subr-1.0 expat-2.0.1_1 kbproto-1.0.3.
Creating bzip'd tar ball in '/var/ports/tree/devel/eggdbus/eggdbus-0.6.tbz'
rmdir: /var/ports/tree/devel/eggdbus/work: Directory not empty
*** Error code 1 (ignored)
=== Generating temporary packing list
Creating package /var/ports/tree/textproc/docbook-420/docbook-4.2.tbz
Registering depends: iso8879-1986_2 xmlcatmgr-2.2.
Creating bzip'd tar ball in
'/var/ports/tree/textproc/docbook-420/docbook-4.2.tbz'
tar: share/sgml/docbook/4.2/ChangeLog: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/calstblx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/catalog: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/catalog.xml: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbcentx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbgenent.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbhierx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbnotnx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/dbpoolx.mod: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.cat: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.dcl: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbook.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/docbookx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/soextblx.dtd: Cannot stat: No such file or directory
tar: share/sgml/docbook/4.2/README: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
*** Error code 1
Stop in /var/ports/tree/textproc/docbook-420.
*** Error code 1
Stop in /var/ports/tree/textproc/docbook-420.
*** Error code 1
Stop in /var/ports/tree/graphics/inkscape.
Regards,
xw
Not that this is a solution to your problem but it might be a possibility
for you to consider, but a couple years back I dropped using make
package(-recursive) and just scripted out making backup packages using
something like the following.
_pkg_bld(){
cd /exports/packages
for package in `ls /var/db/pkg |sed 's/pkgdb.db//'`; do
echo Building package: $package
pkg_create -v -b $package pkg_bld.log 21
done
}
Rather simple way to go about creating final packages and from some
earlier emails to the list there was word of some directories not being
included in final built packages due to empty directories or something
like that so be careful when/if considering something like this.
There are additional flags that can be passed to pkg_create to keep it
from rebuilding the package if it already exists but I have not worked
that into the above example usage.
At some point I also worked in package signing like so,
_pkg_sign(){
cd /exports/packages
for package in `ls *.tbz`; do
echo Signing package: $package
gpg -u 3588E52D -v -ba $package
done
}
Good Luck Regards,
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: package building failure irritation
On Fri, 5 Mar 2010 06:56, des@ wrote: xorquew...@googlemail.com writes: Is there any resolution for this problem? I told you, zfs set mountpoint and ditch nullfs. DES Adding on to this. There were reports in various cases dating back to ~1 year with bad results, possible data loss, hard and soft dead locks when nullfs was used with ZFS. nullfs at one point that I do remember was not recommended to be used at all with ZFS and there exist quite a bit of other functionality in ZFS cloning, snapshots, mountpoint= etc... that serve well enough to not use nullfs at all. Surely in the case above you are talking about packages and in which you really should not need to mount this multiple times as a writable FS, correct me if you feel that it does and lets see why (please provide your process if you do). This should suffice mounting a packages type collection in multiple places: # Mount one dataset wherever you need it. zfs set mountpoint=/path/to/wherever pool/packages # Create a snapshot and clone it for further mountpoints. zfs snapshot pool/packa...@20100305 zfs clone pool/packa...@20100305 pool/packages2 zfs set mountpoint=/path/to/other/dir pool/packages2 If none of this would suffice then your package management needs to be re-thought out. Central FTP, NFS, SMB, RSYNC?. You have plenty of options available but the only one that will be suitable to you your process will be the one that is planned for accordingly and thoroughly. Best of luck, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Automated kernel crash reporting system
On Thu, 4 Mar 2010 07:09, dan.naumov@ wrote: Hello I noticed the following on the FreeBSD website: http://www.freebsd.org/projects/ideas/ideas.html#p-autoreport Has there been any progress/work done on the automated kernel crash reporting system? The current ways of enabling and gathering the information required by developers for investigating panics and similar issues are unintuitive and user-hostile to say the least and anything to automate the process would be a very welcome addition. - Sincerely, Dan Naumov Hi Dan, I am assuming that the output of crashinfo_enable=YES is not what you are talking about is it ? are you aware of it ? The info contained in the crashinfo.txt.N is pretty informative for developers, maybe your talking about another way of submitting it ? Regards, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] extending {amd64|i386} cpu info
On Mon, 1 Mar 2010 19:29, alexbestms@ wrote: jhell schrieb am 2010-03-01: On Fri, 26 Feb 2010 22:19, alexbestms@ wrote: hi there, i always forget how to decipher model and family from the cpu id. of course there're 3rd party tools to do that for you, but instead i decided to hack the kernel. ;) maybe somebody finds these changes useful. cheers. alex What about the other arch's ? I only see i386 and amd64. I would think if this functionality is going to make it in that it should be done consistantly across the board, the way it is now. just had a look at the other archs and in fact implementing these changes is not that easy as on i386 and amd64. talking about consistency: i found the cpu info outputs on arm, i64, etc. to differ from the ones on i386 and amd64. so in fact there is inconsistency present atm. In that case. EEEK. Alright if they are already differing then I certainly see no reason why not to do this. i also think that on some archs it's not possible to output cpu id, stepping, family and model simply because there's no cpu instruction (CPUID or something similar) returning those info for freebsd to use. Man what_was_I_smokin(1) joking; when I wrote that last email while thinking about three things at once. Of course they are going to be different lol. You are quite correct. Sorry. cheers. alex -- jhell -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: `make cleanworld` and /usr/obj/lib32/usr/src
On Mon, 1 Mar 2010 14:52, alexbestms@ wrote: oh. and btw: wouldn't it be reasonable to prevent a user shooting himself in the foot if he has the brilliant idea of setting MAKEOBJDIRPREFIX = / ? alex Trying to match something like this is going to get out of control. Though this is a nice idea but why should a user be prevented from doing such things ?. Boiling down these are not variables that usually have to be changed and if they are changed the user has done a little bit of research and is more advanced than most and recognizes that / is not a option. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: `make cleanworld` and /usr/obj/lib32/usr/src
On Mon, 1 Mar 2010 19:45, alexbestms@ wrote: jhell schrieb am 2010-03-02: On Mon, 1 Mar 2010 14:52, alexbestms@ wrote: oh. and btw: wouldn't it be reasonable to prevent a user shooting himself in the foot if he has the brilliant idea of setting MAKEOBJDIRPREFIX = / ? alex Trying to match something like this is going to get out of control. Though this is a nice idea but why should a user be prevented from doing such things ?. Boiling down these are not variables that usually have to be changed and if they are changed the user has done a little bit of research and is more advanced than most and recognizes that / is not a option. hmmm...so you think something like this won't be useful? alex -- jhell What about the case where MAKEOBJDIRPREFIX=/ usr/obj/dir. I suppose make will fail in this case but I don't have anything to test this situation in ATM. But aside from that typical user never adjusts such things and it adds just a slight bit more overhead to the build that can be avoided altoghter by the user reading what they type. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: `make cleanworld` and /usr/obj/lib32/usr/src
On Sun, 28 Feb 2010 11:54, alexbestms@ wrote:
Gary Jennejohn schrieb am 2010-02-28:
On Sat, 27 Feb 2010 14:49:58 +0100 (CET)
Alexander Best alexbes...@wwu.de wrote:
how about something like this?
Based on a quick look it seems OK to me.
Have you tested it?
i did. it works when `make cleanworld` is being run from /usr/src. i'm not
sure however what the
.if ${.CURDIR} == ${.OBJDIR} || ${.CURDIR}/obj == ${.OBJDIR}
.if exists(${BW_CANONICALOBJDIR}/)
statement is for so i didn't include the lib32 cleanup in that clause. my
guess is that it's used to catch the case where `make cleanworld` is being run
in /usr/obj/usr/src
You can't run make from a obj directory there is no Makefile, Targets or
spoons. ;)
This line here:
BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
Allows the end-user to set MAKEOBJDIRPREFIX in their environment and have
the obj directory somewhere other than CANONICALOBJDIR.
BW is an abbreviation for buildworld.
cheers.
alex
---
Gary Jennejohn
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] extending {amd64|i386} cpu info
On Fri, 26 Feb 2010 22:19, alexbestms@ wrote: hi there, i always forget how to decipher model and family from the cpu id. of course there're 3rd party tools to do that for you, but instead i decided to hack the kernel. ;) maybe somebody finds these changes useful. cheers. alex What about the other arch's ? I only see i386 and amd64. I would think if this functionality is going to make it in that it should be done consistantly across the board, the way it is now. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mktemp(1) in /tmp or $PWD?
On Fri, 26 Feb 2010 05:56, yanefbsd@ wrote: On Fri, Feb 26, 2010 at 2:29 AM, Jonathan McKeown j.mcke...@ru.ac.za wrote: On Friday 26 February 2010 12:03:42 Garrett Cooper wrote: FreeBSD is a great system; if there are ways that I can possibly make it better by adding smart defaults Be careful about that value judgement. There are certainly ways you can change it. Not everyone might feel the change is for the better, and changing the default behaviour of widely-used commands is one change that you might find some people disagree with. I agree that there are some things that I'm going to have to apply on my own personal machines to achieve behavior that I want, and I agree that my way may not be the best way to do things, but that's part of the reasoning why I'm asking whether or not others find some value in what I'm proposing... Thanks, -Garrett Hi Garrett, First off don't get me wrong and I understand where your coming from on this but. GNU/Linux utilities have assumed the lazy system administrators approach for a long time, let me explain. By specifying defaults as said $PWD to find(1) you are now assuming that the user does not want to see any usage info and now has to type -h or maybe --help or possibly -? This is Wrong. Now on the case for mktemp(1) always specifying a /tmp as a default is making the lazy assumption that /tmp will always be usable yes this is BSD, Linux, UNIX but any utility that is going to write and not have a specified path should always write to $CWD and if $CWD is not writable then its a programming mistake. I like knowing that when I issue a command whether it be from a script or from the prompt that I do not have to look elsewhere unless that is what I wanted. Regards, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: junior tasks wiki page - please add stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 18 Feb 2010 17:13, yanefbsd@ wrote: On Thu, Feb 18, 2010 at 11:22 AM, Eitan Adler eitanadlerl...@gmail.com wrote: I made a wiki page[1] to list small odd-jobs that beginners to work on. It is intended to answer the question I'm just starting out with coding, what can I help with? The tasks put on the wiki page should be things that require little programming skill. It would become a lot more useful if people added things to do. [1] http://wiki.freebsd.org/JuniorJobs 1. Who should the wiki content `regulators' be (i.e. project-only folks, outside folks, etc)? Anyone can sign up for an account and because the information reflects on the project, it would be best (IMO) if `proposals' // `tasks' were vetted by someone in the project with sufficient say to prioritize the item. 2. Would it be a good idea to also provide a list of tasks that are non-coding related (or at least have a smaller scope) so that others could assist with in the project to help free up resources? For instance, some folks (like linimon@) really need a junior person (I've debated whether or not I should do it, but I don't want to assume too much responsibility) to do semi-menial tasks like bug triage, feedback, basic administration items, etc to free up Mark's time. That way it would allow someone with less background and exposure to the project to become more integrated with the project, outside of doing an SoC project for instance. Just curious... Thanks, -Garrett It would be awesome if for some way the PR database could be tied into this so items in the database could be promoted as junior tasks. Adding to that, an option in the PR web for someone to be able to vote on certain PR's that should be promoted and ultimately giving a little more free time to the PR admin by not having to visually inspect every PR that has not been categorized for its worth as a junior project, and putting the community as a whole to work in the voting. Ultimately I would see something like the above reducing the PR database greatly and freeing up some man hours for linimon@ so he can get some more coffee ;). Think-Tank open for business ;) Regards, - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLfiAFAAoJEJBXh4mJ2FR+8GcH/j4/44yr/iKUSDHl8GIP6Bhq M6d9rq+rYVuuTO8vJy899XVpYinD0ztFRIpAZb1iQBS6+Tc+PYARllc1BQkKTv0m xAjro78KdrGsoYcIrJ8d/vSlrtV8ojJql7EMZfB9bJyAVX6wAtvnMULn8TvIG6AS QLjasNpi2Zsw+g1dBy416Gy5YnNyZbYEFnh3e67bjF1rxlKSuEWPixOQnEWpEZLh 2G4u4mtZTHnC19zWW/43vW+WbXZBdbcQe8MZr6QnBoSPyjtburHyChKy3ca0szTX TFh/a9Cs84GmW8aDrtYxIGl2GsfZTr8EBuummoSLu8UoLurMA3sW37/xONVni9o= =7fYP -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
On Thu, 4 Feb 2010 05:01, eitanadlerlist@ wrote:
This patch hijacks pgrep's -l
[cut]
This particular section of the patch should probably be left out until its
worked over in a way that it does not print the info message if a process
has been found and killed already.
if (!didAction !pgrep)
{
printf(No matching processes belonging to you were found\n);
}
Thanks for the re-patch, quick and resourceful... ;)
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Feb 2010 07:10, lars.engels@ wrote: On Thu, Feb 04, 2010 at 12:01:26PM +0200, Eitan Adler wrote: This patch hijacks pgrep's -l I'd like to paint the bikeshed with little -p's ;-) If it is a bikeshed then maybe we should make it '-bs' but then again you might just confuse that for 'bullshit'. - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLau/6AAoJEJBXh4mJ2FR+wbYIAJ6Aw9iMCsdNDVFxyksDWxXH iJoSDE3MRC7IUCR/y8CpCfJxKVuXmoIALoMZXE1v8b9SOAyaSydnMcOTd7b6bvEg LMh1hC3KsHp84lWgzu2fra9BBSWQXFkeb1vgunWjwYbV1AM2XnTKJ1eGlWvVK2Pt BxovnoZhOStiSolTUPPhSDcRjHhkZ0906PfvbX2/oWv/qFonXt7aI3t0rj5Y4anF +TcmtCFIvxgvu7LwPriO+0M5Ud99bqMX4UZSeLMTukWZ96tS9KTisfxliZmixG0H OrBzo4IudUr6HLGvZDClhT6RJtlheeUv88GbGCXtOJg5tmH+IpsQD0+e8t09uGo= =HFpu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-ID: alpine.bsf.2.00.1002041147050.27...@pragry.qngnvk.ybpny
On Thu, 4 Feb 2010 11:01, jhell@ wrote:
On Thu, 4 Feb 2010 05:01, eitanadlerlist@ wrote:
This patch hijacks pgrep's -l
[cut]
This particular section of the patch should probably be left out until its
worked over in a way that it does not print the info message if a process has
been found and killed already.
if (!didAction !pgrep)
{
printf(No matching processes belonging to you were found\n);
}
Thanks for the re-patch, quick and resourceful... ;)
The attached patch is for stable/7 and does not have the above printf for
no matching processes. It also cleans up the formatting a little following
the rest of the code and adds the -l flag to the usage statement.
This is only the patch for pkill itself and not for the manual page.
;-)
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLavsEAAoJEJBXh4mJ2FR+WMwH/1FQY4+FV5xLd6Lg2xgjcbG0
ptDjfr5EdIowWeE2EckcmkZGHZa6Z9WL3zcgOHBfJbsm7pchKUoAjzihlk2iW76u
yBHknDs0Wysv7g0y2nA5sDmjAzzJV8xF8W7aGps+eRJYp1dSDQh9h5zRLAKqZXQ+
hmc43ZUOTYsOoMdPcHJUm48og5Q7IiVeh4B7T6PeMaFdolwW8wGwJuXjOzRw4+UH
A6g+bBctFNrLIxj6eb39oxhIXoDv7unwM+JONJKJvtKWOmbVD22VVYSMeNKSOeqX
9SelPiwdBj9ulJfTuRmrpfuPw/J7CpkrIwKsifPqP3DYuKQ8qLiBO/jRJwLNkpA=
=PD/9
-END PGP SIGNATURE-Index: pkill.c
===
--- pkill.c (revision 193627)
+++ pkill.c (working copy)
@@ -182,7 +182,7 @@
pidfilelock = 0;
execf = coref = _PATH_DEVNULL;
- while ((ch = getopt(argc, argv,
DF:G:ILM:N:P:SU:ad:fg:ij:lnos:t:u:vx)) != -1)
+ while ((ch = getopt(argc, argv,
DF:G:ILM:N:P:SU:ad:fg:ilj:lnos:t:u:vx)) != -1)
switch (ch) {
case 'D':
debug_opt++;
@@ -245,8 +245,6 @@
criteria = 1;
break;
case 'l':
- if (!pgrep)
- usage();
longfmt = 1;
break;
case 'n':
@@ -528,10 +526,15 @@
/*
* Take the appropriate action for each matched process, if any.
*/
+ int didAction = 0;
for (i = 0, rv = 0, kp = plist; i nproc; i++, kp++) {
if (PSKIP(kp))
continue;
if (selected[i]) {
+ if (longfmt) {
+ didAction = 1;
+ printf(kill -%d %d\n,signum,kp-ki_pid);
+ }
if (inverse)
continue;
} else if (!inverse)
@@ -550,7 +553,7 @@
if (pgrep)
ustr = [-LSfilnovx] [-d delim];
else
- ustr = [-signal] [-ILfinovx];
+ ustr = [-signal] [-ILfilnovx];
fprintf(stderr,
usage: %s %s [-F pidfile] [-G gid] [-M core] [-N system]\n
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote: On (25/02/2009 17:24), Mel wrote: Hi, attached is a small patch to add threshold support to du(1). I've been using it on 7-STABLE machines for a while, cause I got tired of the noise I get when sorting and then reformatting to human-readable. Especially since sorting isn't part of the equasion I'd like to see all dirs exceeding a given size. I've not updated the manpage on -STABLE yet, should be the same as HEAD. Example usage: # du -xht 20m . 29M./contrib/binutils 52M./contrib/gcc 237M./contrib 35M./crypto 28M./lib 20M./share 55M./sys/dev 139M./sys 545M. I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. -- Mel Hi, I've cleaned up original patch: * fixed style and some bugs * as suggested changed it to use expand_number * implemented support for negative threshold values I find the patch very useful. Does it look ok to be commited, or should I file a PR so it won't get lost once again. Example usage: src/sys/crypto % du -ht 100k 137K./des 482K. src/sys/crypto % du -A -ht +100k 129K./des 446K. src/sys/crypto % du -ht -100k 56K./camellia 11K./salsa20 38K./sha2 9.0K./rc4 68K./des/arch/i386 70K./des/arch 88K./rijndael 37K./via 8.0K./hmac 36K./blowfish/arch/i386 37K./blowfish/arch 85K./blowfish I like it!. This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. Best regards. This message was supposed to arrive 9 hours ago but there was some ISP problems that prevented me from sending it. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote: On (25/02/2009 17:24), Mel wrote: Hi, attached is a small patch to add threshold support to du(1). I've been using it on 7-STABLE machines for a while, cause I got tired of the noise I get when sorting and then reformatting to human-readable. Especially since sorting isn't part of the equasion I'd like to see all dirs exceeding a given size. I've not updated the manpage on -STABLE yet, should be the same as HEAD. Example usage: # du -xht 20m . 29M./contrib/binutils 52M./contrib/gcc 237M./contrib 35M./crypto 28M./lib 20M./share 55M./sys/dev 139M./sys 545M. I'll file a PR for it, if there's no objections to this feature / implementation, the style(9) or the usage of -t. -- Mel Hi, I've cleaned up original patch: * fixed style and some bugs * as suggested changed it to use expand_number * implemented support for negative threshold values I find the patch very useful. Does it look ok to be commited, or should I file a PR so it won't get lost once again. Example usage: src/sys/crypto % du -ht 100k 137K./des 482K. src/sys/crypto % du -A -ht +100k 129K./des 446K. src/sys/crypto % du -ht -100k 56K./camellia 11K./salsa20 38K./sha2 9.0K./rc4 68K./des/arch/i386 70K./des/arch 88K./rijndael 37K./via 8.0K./hmac 36K./blowfish/arch/i386 37K./blowfish/arch 85K./blowfish I would recommend generating this patch as a unified diff or a svn or cvs diff whichever version you checked out your tree with. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 06:55, gleb.kurtsou@ wrote:
On (25/02/2009 17:24), Mel wrote:
Hi,
attached is a small patch to add threshold support to du(1). I've been using
it on 7-STABLE machines for a while, cause I got tired of the noise I get
when sorting and then reformatting to human-readable. Especially since
sorting isn't part of the equasion I'd like to see all dirs exceeding a
given size.
I've not updated the manpage on -STABLE yet, should be the same as HEAD.
Example usage:
# du -xht 20m .
29M./contrib/binutils
52M./contrib/gcc
237M./contrib
35M./crypto
28M./lib
20M./share
55M./sys/dev
139M./sys
545M.
I'll file a PR for it, if there's no objections to this feature /
implementation, the style(9) or the usage of -t.
--
Mel
Hi,
I've cleaned up original patch:
* fixed style and some bugs
* as suggested changed it to use expand_number
* implemented support for negative threshold values
I find the patch very useful. Does it look ok to be commited, or should
I file a PR so it won't get lost once again.
Example usage:
src/sys/crypto % du -ht 100k
137K./des
482K.
src/sys/crypto % du -A -ht +100k
129K./des
446K.
src/sys/crypto % du -ht -100k
56K./camellia
11K./salsa20
38K./sha2
9.0K./rc4
68K./des/arch/i386
70K./des/arch
88K./rijndael
37K./via
8.0K./hmac
36K./blowfish/arch/i386
37K./blowfish/arch
85K./blowfish
Also not to be picky but I can see this being raised in another email at a
later time.
For Each
du -ht +1.5{M,G,T,P}
Would be something nice to compliment this so you do not have to revert
back to say 1440k when wanting to say 1.5m and so on for larger sizes.
Also I think to be fully supportive it should have the capability to do at
the least -N bits +-N bytes.
Thanks for the work that you have done on this.
--
jhell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Support for thresholds in du(1)
On Thu, 4 Feb 2010 23:51, jasonspiro4@ wrote: On Thu, Feb 4, 2010 at 9:30 PM, jhell jh...@dataix.net wrote: I like it!. It looks like a really useful option. Though if you really need to free up a lot of space, try a Freshmeat search[1] for [ disk usage ]. It reveals many tools that look even better, including ncdu[2] which doesn't require Xorg. But I doubt that any of them ship with FreeBSD by default. I think the du manpage[3]'s SEE ALSO section should be revised to include ncdu(1), xdiskusage(1), baobab(1), and kdirstat(1). (Baobab requires Gnome, and KDirStat requires KDE.) What do you think? To me it is a annoyance when I see a man page reference something that is not already installed on the system especially if it does not reference a URL. Back end utilities should really only list their friends in see also and not friends of friends and their friends. ;) My favorite that can run on anything that can run java jre/jdk is sysutils/jdiskreport. Although certain WM's do not work well with java this is a very portable utility. This certainly reduces some piping but as long as it is not integrated upstream it will only become more of a responsibility on FreeBSD's behalf to maintain it. If someone has the original authors email address I would say lets include him on this and see what he thinks. This would probably be the same for the pkill thread that I am involved in to. CC'ing responsible party for that thread. What do you mean? Do you mean that maintaining half a dozen lines of extra code added to pkill(1) would be a burden for the FreeBSD team? :) Yeah. I am more of a lean practitioner so I try to always look for the best way or if you will the least hands on way of managing things. In this case the less code that has to be merged upon update the better and more time that is available to developers to work on much needed other tasks. Five minutes not opening a editor and merging code could better be used getting a cup of coffee to stay awake while hacking on ZFS or utmpx rather than pkill or du. ;) ^ [1]. http://freshmeat.net/search/?q=disk+usage ^ [2]. http://freshmeat.net/projects/ncdu ^ [3]. http://www.freebsd.org/cgi/man.cgi?query=dumanpath=FreeBSD+9.0-CURRENT -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
On Wed, 3 Feb 2010 10:00, eitanadlerlist@ wrote: I added an option to pkill which lists what processes it kills and what signal is sent. If no signals are sent it prints out the same message killall does. Unfortunately that patch works but has unintended operation that can be seen with the following. sleep 1000 pkill sleep No matching processes belonging to you were found [1]+ Terminated: 15 sleep 1 It then kills sleep and still prints no processes belong to you message. Now pkill -v sleep on my system actually causes my Xserver to exit with a unexpected signal 15. Without the patches it works as it should... Overhead endured. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
On Wed, 3 Feb 2010 12:52, jhell@ wrote: On Wed, 3 Feb 2010 10:00, eitanadlerlist@ wrote: I added an option to pkill which lists what processes it kills and what signal is sent. If no signals are sent it prints out the same message killall does. Unfortunately that patch works but has unintended operation that can be seen with the following. sleep 1000 pkill sleep No matching processes belonging to you were found [1]+ Terminated: 15 sleep 1 It then kills sleep and still prints no processes belong to you message. Now pkill -v sleep on my system actually causes my Xserver to exit with a unexpected signal 15. Without the patches it works as it should... Overhead endured. Ugh! ignore the pkill -v comment. Should have noticed the -V instead. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] [patch] pkill verbose option
On Wed, 3 Feb 2010 16:17, eitanadlerlist@ wrote: Yeah - I wasn't sure what else to use. Does the -V work as intended? Is this a worthwhile patch? IMHO the biggest problem with unix system commands is the lack of constancy of the flags. Personally I would like to see pkill have this option as '-l' since pgrep uses '-l' for long output I think it would make more sense if the user is already used to what they expect to find in pgrep be also available in pkill. Other than that it works as expected. ;) On Wed, Feb 3, 2010 at 7:58 PM, jhell jh...@dataix.net wrote: On Wed, 3 Feb 2010 12:52, jhell@ wrote: On Wed, 3 Feb 2010 10:00, eitanadlerlist@ wrote: I added an option to pkill which lists what processes it kills and what signal is sent. If no signals are sent it prints out the same message killall does. Unfortunately that patch works but has unintended operation that can be seen with the following. sleep 1000 pkill sleep No matching processes belonging to you were found [1]+ Terminated: 15 sleep 1 It then kills sleep and still prints no processes belong to you message. Now pkill -v sleep on my system actually causes my Xserver to exit with a unexpected signal 15. Without the patches it works as it should... Overhead endured. Ugh! ignore the pkill -v comment. Should have noticed the -V instead. -- jhell -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: our little daemon abused as symbol of the evil
On Tue, 2 Feb 2010 10:21, kuku@ wrote: Look here: http://www.spiegel.de/fotostrecke/fotostrecke-51396-2.html -- Christoph OH! no! someone quick get a Microsoft Solicitation! I mean solution -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Setting zfs_arc_max value in FreeBSD 8.
On Sat, 23 Jan 2010 04:25, Alexander@ wrote: On Fri, 22 Jan 2010 21:39:48 -0500 jhell jh...@dataix.net wrote: On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? You may want to make sure that vm.kmem_size is set to a value much larger than vfs.zfs.arc_max. Default value may be too small to allow such a large ARC. On a side note, I'm not sure that ZFS is a good match for system with only 1G of RAM. By trial and error on my box with 8G or memory I've figured out that I need to set arc_max ~1G below physical memory size to avoid lockups under load. YMMV. ZFS on this box with 1G has been quite enjoyable actually. With the settings I have posted I have not had any lockup on stable/7 and no sudden freezes or waits for transfers. So this entirely thus far has been a godsend. I had even put this thing through some of the tortures that others have posted to the list and not come up with the same results but better. There is obviously a lot of variables in this between hardware and configurations used so the results are minimal in comparison. With ZFS in place on this machine it performs a little bit under specs for the hardware but I wouldn't expect anything less for such a file-system. You may want to switch to fletcher4 checksums. This is the default in Solaris and 8.0 now. I didn't merge this change to 7-stable as I didn't took the time to analyze if the change for the default has some unwanted implications for existig pools. I will do this and report back with any differences that I find. As for your previous email that arrived I believe after this one, Thank you for your replies I appreciate the feedback. I have a 9-current box with 1GB RAM and ZFS which shows the slow-down after some hours of running (and doing things) too. It would be good to make a list of OS versions and if there are slowdowns or not (anyone with time out there to have a look at the mails and get this info out of the mails / people?). Maybe it is related to changes not in ZFS... Bye, Alexander. Is there any recommendations from anyone ? so there is a basis for what can be tested from. (unixbench|iozone|others) in comparison to the same results version to version ? Thanks -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Setting zfs_arc_max value in FreeBSD 8.
On Sat, 23 Jan 2010 00:19, fbsdlist@ wrote: Good to hear that it's usable for you even on a relatively low-memory system. Now, throw in an SSD for L2ARC, more RAM for ARC (and L2ARC housekeeping) and then it starts to really shine. Can not wait until I can get something like this spinning!. I'm looking at around 6 months before this type of configuration will come into effect and be viable. I'm excited!. As for better than expected performance, in my not-so scientific benchmarks (copying 10G-large files on 8-disk RAIDZ2 pool until filesystem is full) ZFS on FreeBSD did beat the hell out of OpenSolaris on the same hardware. I was really surprised. I'm sure something needed to be tuned on OpenSolaris, but it was nice to see FreeBSD performing so well. --Artem These guys really are doing one hell (maybe 2 or 3 ;]) of a job. Couldn't ask for better people to work on this. On Fri, Jan 22, 2010 at 6:39 PM, jhell jh...@dataix.net wrote: On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? You may want to make sure that vm.kmem_size is set to a value much larger than vfs.zfs.arc_max. Default value may be too small to allow such a large ARC. On a side note, I'm not sure that ZFS is a good match for system with only 1G of RAM. By trial and error on my box with 8G or memory I've figured out that I need to set arc_max ~1G below physical memory size to avoid lockups under load. YMMV. ZFS on this box with 1G has been quite enjoyable actually. With the settings I have posted I have not had any lockup on stable/7 and no sudden freezes or waits for transfers. So this entirely thus far has been a godsend. I had even put this thing through some of the tortures that others have posted to the list and not come up with the same results but better. There is obviously a lot of variables in this between hardware and configurations used so the results are minimal in comparison. With ZFS in place on this machine it performs a little bit under specs for the hardware but I wouldn't expect anything less for such a file-system. -- Thoughts Prayers out to Haiti. jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Setting zfs_arc_max value in FreeBSD 8.
On Wed, 20 Jan 2010 05:14, Alexander@ wrote: Quoting jhell jh...@dataix.net (from Tue, 19 Jan 2010 09:45:58 -0500): On 1/19/2010 5:16 AM, Sherin George wrote: Thanks Ivan :) I found It. add following in /boot/loader.conf === vfs.zfs.arc_max=10244M === I just thought I would give a shout at this for stable/7 as of last week. I am not sure if this is just me but I had tried to adjust zfs_arc_max and found out that it was unadjusted to my value after the system came back up. Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? Can you confirm that you made the modification in /boot/loader.conf, and that you used the double-quotes around the value as shown above? The code in 7-stable regarding this is the same as in 8-stable and 9-current, so if it is done correctly, it has to change accordingly. Bye, Alexander. Yes, The sysctl in question on my machine is/was put in loader.conf with the double quotes. Every time I have set this before I was trying to set it to a value = 512M which with the values below must have not been excepted and fell back to 320M. If I set this to a value of = 511M it works fine which leads me to believe this is limited by some other value listed below ? dmesg: real memory = 1072107520 (1022 MB) avail memory = 1035038720 (987 MB) loader.conf: kern.maxusers=512Not sure if this has anything to do with it. vfs.zfs.arc_min=80M vfs.zfs.arc_max=512M This fails. stays at 335544320. vm.kmem_size=512M vm.kmem_size_max=512MMaybe this one. kern.ipc.semmni=40 kern.ipc.semmns=300 kern.maxdsiz=536870912 kern.maxfiles=16384 There is points in time where I would like to dedicate 2/3 of ram or more using ZFS arc_max but somehow I feel like I have limited this by one of the other values that I had not had the time to look into if they impact larger values of arc_max being set. Thank you, Best regards,, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Setting zfs_arc_max value in FreeBSD 8.
On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? You may want to make sure that vm.kmem_size is set to a value much larger than vfs.zfs.arc_max. Default value may be too small to allow such a large ARC. On a side note, I'm not sure that ZFS is a good match for system with only 1G of RAM. By trial and error on my box with 8G or memory I've figured out that I need to set arc_max ~1G below physical memory size to avoid lockups under load. YMMV. ZFS on this box with 1G has been quite enjoyable actually. With the settings I have posted I have not had any lockup on stable/7 and no sudden freezes or waits for transfers. So this entirely thus far has been a godsend. I had even put this thing through some of the tortures that others have posted to the list and not come up with the same results but better. There is obviously a lot of variables in this between hardware and configurations used so the results are minimal in comparison. With ZFS in place on this machine it performs a little bit under specs for the hardware but I wouldn't expect anything less for such a file-system. -- Thoughts Prayers out to Haiti. jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Setting zfs_arc_max value in FreeBSD 8.
On 1/19/2010 5:16 AM, Sherin George wrote: Thanks Ivan :) I found It. add following in /boot/loader.conf === vfs.zfs.arc_max=10244M === -- Best Regards, Sherin On Tue, Jan 19, 2010 at 3:15 PM, Ivan Voras ivo...@freebsd.org wrote: On 01/19/10 10:19, Sherin George wrote: Hello, I am trying to tune ZFS file system by setting zfs_arc_max value in FreeBSD 8. In solaris, it is achieved like this = For example, if an application needs 5 GBytes of memory on a system with 36-GBytes of memory, you could set the arc maximum to 30 GBytes, (0x78000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in the /etc/system file: set zfs:zfs_arc_max = 0x78000 or set zfs:zfs_arc_max = 32212254720 = But, I couldn't find /etc/system file in FreeBSD. Could some one please guide me to correctly configure zfs_arc_max in FreeBSD 8. You should probably start here: http://wiki.freebsd.org/ZFSTuningGuide and more generally, here: http://wiki.freebsd.org/ZFS I just thought I would give a shout at this for stable/7 as of last week. I am not sure if this is just me but I had tried to adjust zfs_arc_max and found out that it was unadjusted to my value after the system came back up. Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: limits for run away Firefox ?
On Sun, 17 Jan 2010 20:07, jhs@ wrote: Hi hackers I'm tired of my X server occasionaly freezing, swap thrasing, firefox dumps: 4,346,937,344 ~/firefox-bin.core so as a temporary cludge I ran touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core I could put X users in another group, reduce limits, per man login.conf ... RESOURCE LIMITS suggestions of values welcome. Yes 7.1 is old, thats my screen server, till I complete local builds of 7.2 8.0 on other boxes., then I'll upgrade, but I'll still want firefox though I see firefox is still troublesome eg uname -r # 8.0-RELEASE cd /usr/ports/www/firefox/Makefile ; make make# === firefox-2.0.0.20_9,1 is forbidden: too many security issues cd ../firefox3 ; make # is OK, runs on 8.0 i686, but on amd64 fails with GLib-WARNING **: g_set_prgname() called multiple times so I'm pausing for perspective, comment invited :-) Cheers, Julian Is it a possibility for you to add something like this to your ~/.login_conf me:\ :umask=027:\ :lang=C:\ :charset=en_US.ISO8859-1:\ :coredumpsize=0 Of course, adjust accordingly. Maybe you could just run it in a different class that you can setup globally in your login.conf as well so you do not have to turn off core dumps for your user entirely. At least you wont have the core dumps but this may not exactly be what you are looking for. Best of luck. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
On Tue, 5 Jan 2010 08:32, stephen@ wrote: Victor Sudakov wrote: But to hell with this. I started the topic because I think something is wrong with SVN to CVS export, which upsets cvsup and causes Checksum mismatch errors. Is anybody willing to look at it? I second Victor's request. Though I support the request for fixing things that pose a possible problem and it is also a problem(maybe) I see on my end, I would really like to see this move forward and merge what we have now from CVS - SVN and stop backpedaling commits so we can gain some resources back for the cluster. If this can be done I will donate whatever time I can to help assist with the move. -- Thu Jan 7 12:51:49 2010 jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Patch to Makefile.inc1 to mention which kernel config is being installed
On Tue, 5 Jan 2010 08:29, david@ wrote: In the usual case where a machine is (only) used to build its own kernel, this is admittedly of no benefit. But for build machines that are used to build kernels for other machines (as well as themselves), it kinda bugged me that I was being told which kernels were being built, but not which one was being installed. Sure, I could recall that the first one built was being installed ... but why not have Makefile.inc1 tell us, just as it tells us which is being built? Before the patch, grepping through the typescript of a build for ^ would yield: Building an up-to-date make(1) World build started on Mon Jan 4 04:47:37 PST 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Jan 4 05:00:40 PST 2010 Kernel build for GENERIC started on Mon Jan 4 05:00:40 PST 2010 stage 1: configuring the kernel stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for GENERIC completed on Mon Jan 4 05:01:32 PST 2010 Kernel build for ALBERT started on Mon Jan 4 05:01:32 PST 2010 stage 1: configuring the kernel stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for ALBERT completed on Mon Jan 4 05:02:20 PST 2010 Kernel build for JANUS started on Mon Jan 4 05:02:20 PST 2010 stage 1: configuring the kernel stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for JANUS completed on Mon Jan 4 05:03:07 PST 2010 Installing kernel Making hierarchy Installing everything Removing old files (only deletes safe to delete libs) Old files removed Removing old directories Old directories removed stage 2.2: rebuilding the object tree stage 4.4: building everything Removing old libraries Old libraries removed After the patch: Building an up-to-date make(1) World build started on Tue Jan 5 04:48:19 PST 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Jan 5 05:01:26 PST 2010 Kernel build for GENERIC started on Tue Jan 5 05:01:26 PST 2010 stage 1: configuring the kernel stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for GENERIC completed on Tue Jan 5 05:03:28 PST 2010 Kernel build for ALBERT started on Tue Jan 5 05:03:28 PST 2010 stage 1: configuring the kernel stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for ALBERT completed on Tue Jan 5 05:05:12 PST 2010 Kernel build for JANUS started on Tue Jan 5 05:05:12 PST 2010 stage 1: configuring the kernel stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for JANUS completed on Tue Jan 5 05:06:53 PST 2010 Installing kernel GENERIC Making hierarchy Installing everything Removing old files (only deletes safe to delete libs) Old files removed Removing old directories Old directories removed stage 2.2: rebuilding the object tree stage 4.4: building everything Removing old libraries Old libraries removed Attached patch is against head; for the above, I had patched stable/7. Thoughts? Peace, david I see this serving as good verification to the user that the kernel they meant to configure is being installed. I would like to see this make it in. -- Thu Jan 7 12:44:52 2010 jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: something fails with svn
On 1/1/2010 6:24 AM, Ed Schouten wrote: * jhelljh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. You know really... I did not see anything that you have replied with to be constructive criticism At all. And personally if you really want to reply with remarks of Would you mind sharing your findings Sherlock Holmes You can then keep your comments to your self as I do not find them useful and my name is not Sherlock Holmes. Secondly I would expect a much more intelligent remark to come from someone with your background but I guess that comes with age. So my suggestion in constructiveness to you would be to think harder before you critique a post of the very same nature as the one you posted. As regards to the OP the email was meant as a confirmation to the author that the problem did lye on his end and that by paying closer attention to the paths that were displayed in the OP would have revealed the problem. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: something fails with svn
On 1/1/2010 8:21 PM, Kevin Oberman wrote: Date: Fri, 01 Jan 2010 19:20:54 -0500 From: jhelljh...@dataix.net Sender: owner-freebsd-sta...@freebsd.org On 1/1/2010 6:24 AM, Ed Schouten wrote: * jhelljh...@dataix.net wrote: With those remarks I will leave it up to your honed skills to figure out. If you don't have anything constructive to say, please refrain from responding to any message on these lists. The purpose of these lists is to help each other. You know really... I did not see anything that you have replied with to be constructive criticism At all. And personally if you really want to reply with remarks of Would you mind sharing your findings Sherlock Holmes You can then keep your comments to your self as I do not find them useful and my name is not Sherlock Holmes. Secondly I would expect a much more intelligent remark to come from someone with your background but I guess that comes with age. So my suggestion in constructiveness to you would be to think harder before you critique a post of the very same nature as the one you posted. As regards to the OP the email was meant as a confirmation to the author that the problem did lye on his end and that by paying closer attention to the paths that were displayed in the OP would have revealed the problem. OK. I will try to say something constructive. You seem to think that clever, useless comments make you look good. As someone who has been working with FreeBSD and the FreeBSD community for a long time, all you really do is make yourself look juvenile, arrogant, and rude. You are a prime example of why many people approaching the FreeBSD community for help claim that we are an arrogant and rude bunch. That's great and all but have you read the reply that I had originally made to the OP. It does not seem like it from your comments. The information content of your messages approaches zero. Maybe the problem is trivial and obvious to you. Maybe it would be to Ed, if he could spot it. Now, if you have never missed an obvious bug until you asked someone why the code would not work, you are either truly exceptional (along with the adjectives listed above) or have written little or no code of your own. Please either provide reasonable assistance when responding to questions or don't reply at all. No one likes a smart ass, Reasonable assistance I think that was pretty reasonable, I do not recall anyone paying something for anything I have said and it seemed to me that he was asking for more of a confirmation. plonk I do not like smart asses either, which in turn is why I am still replying to comments about the followup and why I don't know that I feel I should have to defend my self on this matter. For one: The followup that I had made as I already stated was confirming the problem was on his end and in no way that I see was offending, maybe I could have choose different words but that does not relieve the response I had received after from Ed. For two: If you want to call someone something call them by the respective name or email address that they have spoken with. I do not ever recall naming Ed anything other than his own name nor anyone else. As spoken do on to others as you would do onto your self. I repeat my name is not Sherlock Holmes. Thirdly: Constructive ? there was nothing non-constructive about the followup I had made. I have missed plenty of things in the past and would never claim otherwise and the information that I offered certainly was not complete but was meant not to be, and not in a critiquing manner. -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: something fails with svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 31 Dec 2009 06:18, ed@ wrote: * jhell jh...@dataix.net wrote: Take a look at your git config. The problem lies there and is very visible. After you are done fixing that re-read the whole email that you posted. Would you mind sharing what causes the problem then, Sherlock Holmes? I would say it is elementary my dear Watson but I really do not feel like calling you dear and I certainly do not want to take Roberts last name in vain. With those remarks I will leave it up to your honed skills to figure out. - -- Thu Dec 31 21:38:14 2009 jhell -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJLPWDPAAoJEJBXh4mJ2FR+fzEH/10sPwSo0gt8NgSwXGP05PLt dehayjOEs7gm3PBTKgT43IvBU82sAQxPueVSGVzAKsNJomG4x+pST2t7NYYZ81lL DioRCgRInYUvAMz2bM8b3xemvwaLLjLq9Fkzh3pxw3HOXygQywK2Az+4maKdLeSg CQRcGAZGgAry9zCljo56v4Ur85MAA00xB5aY33nV1xKYTk46+Suv4P3tx6PaMKLt Dp3KbezL5N3ZbHtP0NC3AMNGxam8Vkm+ZjMEUGYQoG3shu3F9nrgLOUzf13Deper Izm3Wx7HCsv06KT502MbiNL3029vYZq4HFl7A7LfplyP47nDMWFZ8q4Q2G4ElrA= =ImPu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: something fails with svn
On Tue, 29 Dec 2009 17:18, oliver.pntr@ wrote: Hi list! Something fails, when updated the FreeBSD's svn repo to git. Since yesterday I get this warning: $ git svn rebase ... M sys/boot/pc98/kgzldr/crt.s Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/kmacy/releng_7_2_fcs/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/stable/8/sys/contrib/pf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/user/peter/kinfo/sys/contrib/pf r201153 = 2a0c8903699f2e4ff17312c753e335424eeac5e3 (refs/remotes/git-svn) M sys/powerpc/conf/DEFAULTS M sys/sparc64/conf/DEFAULTS M sys/ia64/conf/DEFAULTS M sys/sun4v/conf/DEFAULTS M sys/pc98/conf/DEFAULTS M sys/i386/conf/DEFAULTS M sys/amd64/conf/DEFAULTS Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/cddl/contrib/opensolaris Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/dev/acpica Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/sys/contrib/pf r201164 = c4051399b1b56820b010acba9f5f0e2953f5be70 (refs/remotes/git-svn) M etc/rc.d/named M etc/mtree/BIND.chroot.dist M etc/namedb/named.conf Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/etc r201173 = d70d011b0c38f8a35845a3a63e6ba60f2f04774b (refs/remotes/git-svn) M usr.sbin/zic/Theory M lib/libc/stdtime/tzfile.5 Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc/stdtime Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/lib/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/libc Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/head/usr.sbin/zic Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist Couldn't find revmap for svn://svn.freebsd.org/base/stable/7/vendor/tzcode/dist/zic r201184 = 47c9db23979a71f805ff5f11d0574ae1ed83a581 (refs/remotes/git-svn) ... the git config is: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [svn-remote svn] url = svn://svn.freebsd.org/base/stable/7 fetch = :refs/remotes/git-svn Is this a user error (my), or it's an mismerge or repo fail git / or freebsd's svn? SVN never has problems It's powered by FreeBSD ;) Take a look at your git config. The problem lies there and is very visible. After you are done fixing that re-read the whole email that you posted. -- Tue Dec 29 23:28:28 2009 jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Suggestion: rename killall to fkill, but wait five years to phase the new name in
On Tue, 22 Dec 2009 01:31, jasonspiro4@ wrote: Dear Craig, thanks for maintaining the killall command on Linux. Dear hackers, thanks for maintaining it on FreeBSD. Naming it the same as System V killall, which just kills all processes, can wreak havoc. When someone types a standard Linux killall command line as root on a Solaris or HP-UX server, System V killall runs and kills all processes. It might be good if you'd rename it to something else. Not akill (All Kill): it looks like IRIX probably ships with something called akill already, so this would be confusing. Maybe fkill (Friendly Kill). You could do this in phases: for the first five years, /usr/bin/killall could print a warning onscreen, then function as usual. After five years, it could cease to function unless you call it as fkill. Craig, and hackers, are you both willing to do this? -Jason This is what shell aliases are for and what a system admins job consist of. If it gives you that much of a problem just alias it out for your self in your .cshrc .shrc .bashrc .bash_profile etc. If you want to change something on a more per user basis figure out how to setup a skeleton directory so when a new user is created they get all the files from that skel copied into there home. If it is more of a system-wide change then the shell files in /etc will probably be of more use. PS: Applying your changes to a mailing list are not const. -- Tue Dec 22 14:09:40 2009 jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysinstall colours
On Fri, 9 Oct 2009 21:52 +0200, alexbestms@ wrote: hi there, sysinstall is probably one of those ancient relics everybody tries to avoid dealing with from a developers point of view but i just found this beautiful screenie of a (probably) ncurse-based installer: http://www.phoronix.net/image.php?id=yoper_2009_betaimage=yoper_dresden_7_lrg i was surprised how much better it looks with those nice colours compared to sysinstall. is there any way the sysinstall colours could be adjusted (without a lot of work) to also feature such beautiful colours? i had a quick look at the sysinstall, libdialog and ncurses sources and to me it seems that to change sysinstall's colours the hardcoded values of COLOR_BLACK COLOR_RED COLOR_GREEN COLOR_YELLOW COLOR_BLUE COLOR_MAGENTA COLOR_CYAN COLOR_WHITE have to be changed in contrib/ncurses/ncurses/base/lib_color.c or is there an easier way? because this would of course affect all apps that are linked to ncurses. cheers. alex sysinstall looks like this too when it is ran in a gnome terminal or some other terminal that is ran in a X environment. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 2 Oct 2009 17:17 -, glarkin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremy Lea wrote:
Hi,
This is off topic to this list, but I dont want to subscribe to -chat
just to post there... Someone is currently running a distributed SSH
attack against one of my boxes - one attempted login for root every
minute or so for the last 48 hours. They wont get anywhere, since the
box in question has no root password, and doesn't allow root logins via
SSH anyway...
But I was wondering if there were any security researchers out there
that might be interested in the +-800 IPs I've collected from the
botnet? The resolvable hostnames mostly appear to be in Eastern Europe
and South America - I haven't spotted any that might be 'findable' to
get the botnet software.
I could switch out the machine for a honeypot in a VM or a jail, by
moving the host to a new IP, and if you can think of a way of allowing
the next login to succeed with any password, then you could try to see
what they delivered... But I don't have a lot of time to help.
Regards,
-Jeremy
Hi Jeremy,
You could set up DenyHosts and contribute to the pool of IPs that are
attempting SSH logins on the Net:
http://denyhosts.sourceforge.net/faq.html#4_0
It also looks like there's been quite a spike of SSH login activity
recently: http://stats.denyhosts.net/stats.html
Hope that helps,
Greg
- --
Greg Larkin
http://www.FreeBSD.org/ - The Power To Serve
http://www.sourcehosting.net/ - Ready. Set. Code.
http://twitter.com/sourcehosting/ - Follow me, follow you
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKxm4H0sRouByUApARAtnPAKCQuivQdE1s0ZZnUO6qVWA87N8ZKgCgjyYD
Tbv+hWI+KoXYsEpt0n4gW5k=
=xCz7
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Another temporary to long term solution might be the following utilities,
ports/security/sshguard-pf ports/security/expiretable
This is more of a pf based solution so that's up to your policies and decision.
Giving thanks to the post about DenyHosts I didn't know that existed till this
point.
Best regards.
- --
%{+
| dataix.net!jhell 2048R/89D8547E 2009-09-30 |
| BSD since FreeBSD 4.2Linux since Slackware 2.1 |
| 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E |
+%}
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (FreeBSD)
iQEcBAEBAgAGBQJKxoxtAAoJEJBXh4mJ2FR+BLQIAIm4nAh8TinDB/QOI6RX2xxO
CSv46ZxoRlr2uv3FF5LmIVhPt0tskSrO+WLP0Xjm2ORB05tiFRpbzMBRawH41J1p
0USI90j+y9UzXinGRX9vt3GAofRkfuQuXXMUMAwTCZY1+EyzOP/K0dfRTSTj24LH
386epgCU3FA8S9UqKSPSdpQNxf+Yq/urd6ykfOTtcMUh/m2bakYIgwtVb4zOe+34
lpTlsXxuPcv9WtcOkqkj8LhZgFYKTRajfiw/G8cCnHqlaKuSDSH1hPEu7ePUAC5o
wj6TZWh186astBg2WtfIke5zKKQz2ELyT5a3GvhWxR4/l9QWN5F0ZX7TuzaWK1M=
=vtNQ
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
