[PATCH] misc/18466
In browsing through the old, open, PRs I found misc/18466 (from May, 2000). It's got the potential to be a source of substantial confusion, so it seems to be worth addressing. The fix seems trivial, and I've attached a very simple patch to sysinstall.h that should fix the problem. I'm relatively sure there are other, preferred ways of fixing the issue, and I'd be more than happy to see some feedback. - Jeff Jirsa -- == Jeff Jirsa [EMAIL PROTECTED] HMC 2003 == --- sysinstall.h.orig Sun Feb 9 15:02:25 2003 +++ sysinstall.hMon Feb 10 11:06:54 2003 @@ -72,7 +72,13 @@ #endif /* device limits */ -#define DEV_NAME_MAX 64 /* The maximum length of a device name */ + /* The maximum length of a device name */ + +#if (__FreeBSD_version 50 defined _POSIX_PATH_MAX) +#define DEV_NAME_MAX _POSIX_PATH_MAX +#else +#define DEV_NAME_MAX 64 +#endif + #define DEV_MAX100 /* The maximum number of devices we'll deal with */ #define INTERFACE_MAX 50 /* Maximum number of network interfaces we'll deal with */ #define IO_ERROR -2 /* Status code for I/O error rather than normal EOF */
Re: what would cause a server to behave this way ?
On Sun, 5 May 2002, Gary Stanley wrote: I had that EXACT problem. I do not know the cause. 1.) Email Server 2.) Qpopper, Sendmail, the normal crap for a email server ;-) 3.) 2 times a day, or more, the server would be unresponsive. Only solution I found, was a hard reboot. I can -not- track this problem down, after going crazy over it, I moved my lusers back over to my 4.2-STABLE machine. I've had the same situation. The only reason I never tried to track it down is that it only happened on an SMP box with flaky hardware (locks during large compiles - yet runs fine during large FTP/SCP transfers and cpu benchmarks). The last time this occured the box was 80% idle, four users logged in, and one popping (I know this because one of the windows I had open was running top) - everything stopped responding, but the connections stayed active and the syslog kept logging events until powercycled (oddly enough, the one user was popping often enough that the tcp connection seems to have never completely closed... her logins appear in the logs for 20 minutes after the rest of us were sure the box had completely frozen)... - Jeff == Jeff Jirsa [EMAIL PROTECTED] HMC Unix Admin == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5
On Thu, 2 May 2002, Matthew D. Fuller wrote: What do people think of using the external lock file (well, I can't actually think of any OTHER way to do it, so...)? I'm thinking /var/run, but on the flipside just putting it in /etc might be cleaner. Comments? Feel free to correct me if I'm wrong, but /var/run seems like the more logical answer. Read-only / filesystems would have a hard time creating temp lock files in /etc. If nothing else, make it something that's easily configurable to avoid problems with read only filesystems. - Jeff == Jeff Jirsa [EMAIL PROTECTED] == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
logging securelevel violations
I've noticed that currently, violations of securelevel are aborted, but not
typically logged. It seems like in addition to aborting whichever calls are
in progress, logging an error might be beneficial. I recognize that this
goes along the same lines as logging file permission errors, but if a file
is marked immutable, the implicit value of the file should suggest that one
might want to be able to audit attempted changes to that file.
A case in point: /usr/src/sys/kern/kern_linker.c (4.5 STABLE):
int
linker_load_file(const char* filename, linker_file_t* result)
{
...
/* Refuse to load modules if securelevel raised */
if (securelevel 0)
return EPERM;
.
Would the following not work?
int
linker_load_file(const char* filename, linker_file_t* result)
{
...
/* Refuse to load modules if securelevel raised */
if (securelevel 0)
{
log(LOG_ERR, Unable to load module %s: securelevel violation \n,
filename);
return EPERM;
}
...
So, my questions are: Why shouldn't it be done? What simple problems am I
overlooking? (Would such a contribution have a chance of making it into
5.0?)
- Jeff
=
Jeff Jirsa
[EMAIL PROTECTED]
=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
