Re: Password Security
VeeJay wrote: On 11/23/06, Olivier Nicole [EMAIL PROTECTED] wrote: And how can one into the System by booting from a CD if it still requires the Password even in Single User mode? Booting from CD, floppy or hard disk is slected at BIOS level. Booting in single or multi user mode is at Operating system level. Booting is in the following order: 1) BIOS select what medium to boot from 2) the operating system boot from the selected medium So when it comes to the Single user password, itis already at stage 2) it has passed the stage 1 (booting from hard disk ofr CD) without password. Olivier So, it means, that I should take the following steps 1. Password on BIOS 2. Change the order of booting i.e. When system is installed and working once, then I just the change the Booting FIRST from HardDisk. 3. Put the password on Single User mode. So, what more? Do you people think that I have got somehow security barrier for unauthorized access? Not much. Default FreeBSD install has two more places where one can influence booting with console access - boot blocks and loader. To disable the access to OK prompt of boot blocks create file /boot.config with '-n'. To disable access to loader put autoboot_delay=-1 and beastie_disable=YES into /boot/loader.conf. You can also instead put password=... into it and the loader will then require password to allow access to it. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
Skylar Thompson wrote: Michal Mertl wrote: No! Kernel threads (e.g. handling interrupts) aren't that much different to normal processes. Logical CPUs on a single HTT capable CPU share most of the CPU logic, especially all the external stuff (handling interrupts). Scheduling handling of interrupts on the secondary/logical core wouldn't probably help performance at all (if that is at all possible). Could you clarify note 20031022 in /usr/src/UPDATING? It states that HTT CPUs are used for interrupts if they are detected, even if they aren't used by regular processes. Was this something that just showed up in pre-6.x releases? I think it means that if an interrupt would for some reason be signalled to the unused logical core it wouldn't be lost or something. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP detection
backyard píše v čt 31. 08. 2006 v 07:45 -0700: --- Michal Mertl [EMAIL PROTECTED] wrote: Skylar Thompson wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] wrote: I've read that SMP should be disabled for performance issues (I did not know that before installing freebsd). I have a P4 3GHz with hyperthreading technology. I have the SMP-GENERIC kernel and it only launches one cpu. So, I've decided to disable SMP from BIOS. Is that ok?, knowing that I have a Smp enabled kernel? or should I install one without smp? If so, is there a way to install one already precompiled? Thanks in advance -- http://jordilin.wordpress.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] if the system runs with one cpu now and you don't enable smp with HT with the sysctl variable then you should be ok. If your not doing SMP then recompiling the kernel for single processor mode will make things run a little quicker because the SMP code won't come into play. with HT disabling in FreeBSD is more for the security issues about a potential exploit whereby one process in one pipe can access the priveledged information of a process in another pipe because the two cores share one processor cache and thus one cache table. To my knowledge this hasn't been exploited yet. If you just install the generic kernel you it should be only the uniprocessor one. I would just do a: cd /usr/src make buildworld make KERNCONF=GENERIC buildkernel make KERNCONF=GENERIC installkernel as opposed to a binary version assuming you haven't updated yet you won't have to install world but I believe it must have the build in the source tree to build a kernel. On your P4 though the difference between SMP and uniproc may not be worth the trouble because I don't think much of a gain would be made. on a P1 a much different story... if you aren't concerned with bad users or hackers hitting the box I would just enable HT with the sysctl variable. This will not make things run slower at all, just (in theory) less secure, which is why the veriable was created in the first place as I recall. If you are concerned I would wait until you update your system and then just build a GENERIC/CUSTOM kernel without the SMP option set. -brian I will disable smp from bios. If I have a smp kernel, I suppose there will be no problem after all. Would that be ok? The problem with having SMP enabled is that the smp kernel only detects one cpu and the system monitor only features one cpu as well as gkrellm (in Linux it shows two cpus). When compiling the system monitor shows the cpu at a maximum of 50%, so what's going on with the other 50%? writing machdep.hlt_logical_cpus to 2 in loader.conf does not solve anything. I believe FreeBSD uses the other logical CPU to handle hardware interrupts, which can still help perormance. You can check dmesg to see how it's actually handling it. No! Kernel threads (e.g. handling interrupts) aren't that much different to normal processes. Logical CPUs on a single HTT capable CPU share most of the CPU logic, especially all the external stuff (handling interrupts). Scheduling handling of interrupts on the secondary/logical core wouldn't probably help performance at all (if that is at all possible). When FreeBSD sees logical CPUs it means HTT is either enabled in BIOS or that disabling HTT in BIOS does not hide the CPUs to FreeBSD (bug in BIOS/FreeBSD). Until you enable scheduler to schedule tasks to HTT cores (with machdep.hyperthreading_allowed=1 in loader.conf) (disabled by default due to mentioned security/performance reasons) machine won't utilize the logical HTT CPUs. Therefore total CPU utilization won't be more than 50%, because there are the (unused) logical CPUs which don't get scheduled tasks. are you sure about this??? Almost sure but can't check at the moment. I believe there were problems when all HTT CPUs weren't launched sometimes (when HTT wasn't disabled with BIOS), so the logical CPU cores are started and fully visible but only run the idle kernel thread (are 100% idle). I would have figured the scheduler wouldn't see the other core at all without this option set and so it wouldn't be used in calculating load at all. 50% on a compile is fairly normal from my experience. I don't have too much experience with HT
Re: SMP detection
Skylar Thompson wrote: Jordi Carrillo wrote: 2006/8/30, backyard [EMAIL PROTECTED]: --- Jordi Carrillo [EMAIL PROTECTED] wrote: I've read that SMP should be disabled for performance issues (I did not know that before installing freebsd). I have a P4 3GHz with hyperthreading technology. I have the SMP-GENERIC kernel and it only launches one cpu. So, I've decided to disable SMP from BIOS. Is that ok?, knowing that I have a Smp enabled kernel? or should I install one without smp? If so, is there a way to install one already precompiled? Thanks in advance -- http://jordilin.wordpress.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] if the system runs with one cpu now and you don't enable smp with HT with the sysctl variable then you should be ok. If your not doing SMP then recompiling the kernel for single processor mode will make things run a little quicker because the SMP code won't come into play. with HT disabling in FreeBSD is more for the security issues about a potential exploit whereby one process in one pipe can access the priveledged information of a process in another pipe because the two cores share one processor cache and thus one cache table. To my knowledge this hasn't been exploited yet. If you just install the generic kernel you it should be only the uniprocessor one. I would just do a: cd /usr/src make buildworld make KERNCONF=GENERIC buildkernel make KERNCONF=GENERIC installkernel as opposed to a binary version assuming you haven't updated yet you won't have to install world but I believe it must have the build in the source tree to build a kernel. On your P4 though the difference between SMP and uniproc may not be worth the trouble because I don't think much of a gain would be made. on a P1 a much different story... if you aren't concerned with bad users or hackers hitting the box I would just enable HT with the sysctl variable. This will not make things run slower at all, just (in theory) less secure, which is why the veriable was created in the first place as I recall. If you are concerned I would wait until you update your system and then just build a GENERIC/CUSTOM kernel without the SMP option set. -brian I will disable smp from bios. If I have a smp kernel, I suppose there will be no problem after all. Would that be ok? The problem with having SMP enabled is that the smp kernel only detects one cpu and the system monitor only features one cpu as well as gkrellm (in Linux it shows two cpus). When compiling the system monitor shows the cpu at a maximum of 50%, so what's going on with the other 50%? writing machdep.hlt_logical_cpus to 2 in loader.conf does not solve anything. I believe FreeBSD uses the other logical CPU to handle hardware interrupts, which can still help perormance. You can check dmesg to see how it's actually handling it. No! Kernel threads (e.g. handling interrupts) aren't that much different to normal processes. Logical CPUs on a single HTT capable CPU share most of the CPU logic, especially all the external stuff (handling interrupts). Scheduling handling of interrupts on the secondary/logical core wouldn't probably help performance at all (if that is at all possible). When FreeBSD sees logical CPUs it means HTT is either enabled in BIOS or that disabling HTT in BIOS does not hide the CPUs to FreeBSD (bug in BIOS/FreeBSD). Until you enable scheduler to schedule tasks to HTT cores (with machdep.hyperthreading_allowed=1 in loader.conf) (disabled by default due to mentioned security/performance reasons) machine won't utilize the logical HTT CPUs. Therefore total CPU utilization won't be more than 50%, because there are the (unused) logical CPUs which don't get scheduled tasks. As far as know - trying to use HTT normally hurts performance and only a very special load on a machine can show increase in overall performance. Newer Intel CPUs have better HTT (probably meaning less sharing of stuff among the HTT cores - towards current trend - multi-core) and there they say it performs quite good with real world load to handle the logical cores as separate CPUs. Of course (if you built purpose built appliance) you can squeeze more from the HW when you exactly know what you need to do - you have some task(s) which do the data analysis and kernel threads which do the interrupt processing/data shifting) - than effectively using HTT might be possible (I have never heard of anyone effectively using HTT). Newest Intel CPUs don't bother with HTT - they are multicore - close to nothing is shared among (logical) CPUs. You would see each of these CPUs as a CPU in FreeBSD and they will get scheduled tasks to finish. Michal
Re: memory usage
Jonathan Horne wrote: On Sunday 07 May 2006 12:09, Jonathan Horne wrote: i have a server that has 2GB ram, recently upgraded from 1GB ram. it runs apache2.0 with php5, sendmail with spamass-milter, dovecot, mysql5.0, cacti, and a couple other small things (like snmp, my bx irc shell, etc). when ever i look at the memory usage (via phpsysinfo, or cacti graphs), its nearly always showing less than 100mb of ram available. top shows several perls (probably spamassassin), 8 or so httpds (typical), but that would probably only account for (a liberal guess) 500-600 mb of ram. is there a good way to find out where this bottomless ram funnel leads to? or, should this behavior just be considered typical? thanks, jonathan update... i just upgraded to the new phpsysinfo rc2, and it shows more detailed information about what the memory usage is doing. it shows that 1.57GB is being used by buffers. what is the significance of 1.57GB of memory being used by 'buffers'? I would expect a question like this is somewhere in the FAQ. It is typical that you only see a couple of hundred kilobytes of free memory on a (at least a little used) FreeBSD system. The system allocates 'physical' memory as needed (as long as there is some free) and only when there is no free memory, it starts to reuse some of the 'almost' free memory. 'Almost' free memory is mainly disk cache (your buffers). This is nothing to worry about. You can see there is a memory shortage when there is some swapping during normal workload (in top there appears kb in/out on the swap line). It is neither anything to worry about when you have some swap space used - FreeBSD is rather aggresively copying parts of memory to swap when it feels to. As long as it doesn't need to use the data in the swap often it's an optimization - even disk cache is better usage of your memory then inactive parts of your programs' memory. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill Moran wrote: I've been asked to make some hardware recommendations, I'm hoping some folks on the list can make some suggestions. We're looking hard at getting either Intel dual-core procs, or getting hyperthreaded procs with huge (8M) caches. We currently have a few dual proc Intel HT machines that we can test out our workload on, and I'm trying to get a feel for how to determine if a larger cache size will generate better performance than replacing HT procs with full-blown dual-core procs. We're looking at the 6850 from Dell, which supports both processor families: I can't answer your question either but I'd like to raise a couple of questions. If I won't help you I would at least (I hope) learn a little from reactions :-). As far as I know Intel boxes scale quite badly to larger SMP configurations because of at least partially shared FSB which limits memory throughput and which is also consumed great deal by cache coherency maintenance traffic I believe. Dual core may help a little I suppose (I would expect that Intel engineers made memory snooping a little more efficient when accesses are going through one piece of silicon (e.g. the cache coherency traffic's pressure on FSB should be lower between the cores on the same die in comparison to separate cores)). As you may have guessed by now I think that there's some possibility that you would get better performance with AMD Opteron based solution (I know that Dell doesn't normally sell it though) which probably scaler better or even something more exotic (Sun Hardware - UltraSparc, T processors). Even when there isn't pressure on the I/O hardware in your case you may have suboptimally configured PostgreSQL. I believe that PostgreSQL processes do not tend to grow much (at least in comparison to other RDBMS engines). I think that the explanation by psql people is that the huge amounts of memory other engines are using is often used for caching the data and that they (psql) believe that the operating system should be doing that (otherwise you waste memory on caching both in the OS and in the application). With huge databases you should at the end become I/O bound (or at least there must be big I/O traffic) and then I would agree with psql people that there's not much point replicating OS caching in the DB engine. But if crucial parts of working data fit into the memory I would expect that storing them in process should be beneficial. I expect there must be at least a little data verification and shuffling before psql uses the pages from the DB files. Maybe the amount of this work is negligible with real disk I/O, but it may play some role when no real disk I/O is involved. Another explanation why PostgreSQL doesn't grow much may be that they use a lot of shared memory and this is in general probably rather scarce resource (at least the users have to configure something rather low-level to have it up and running). What are your needs regarding the SQL engine anyway? Can't the needs be fulfilled by something other than PostgreSQL? I hate to say that, but possibly MySQL? Or can Firebird be better? I don't know firebird much but I think that it is quite full-featured and although it isn't such widespread it has great performance at least in some benchmarks. What about the operating system? I haven't seen FreeBSD mentioned in your question but I suppose you are running it (because you write to a FreeBSD ML). What about Linux? (Open)Solaris? I think when you are in such big need for performance you shouldn't try just one solution. We (FreeBSDers) would of course like to help you to get the best performance from our favorite OS but maybe you will help make FreeBSD better if you find your application runs considerably better on something else and someone may later find the reason. Last I would like to only express my belief that bigger cache may in fact help you but that nobody can probably say it in advance. Regards Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Attacking our pc router at work
Mark Jayson Alvarez wrote: Hi, I have one question. What if I change my ip and mac address at the same time to that of our pcrouter's ip and mac... Will this going to kick out that router in our network, causing the rest of the entire lan to be out of service?? No one's gonna caught me right?? Arpwatch can only watch if an ip address has moved to another mac address but not when both ip and mac has moved to another ip and mac... Do you know any possible solution to this?? Your question is off topic for this list. Use inteligent switches (not hubs) and port security (you can allow only a specific MAC address behind a switch port). You could also use static entries on the switch for some MAC addresses (entry on a switch is a MAC address + port behind which the address can be found) but that isn't as safe. An attacker can generate traffic with lots of source MAC addresses. Every switch has limited memory to store the MAC addresses and usually when the table is full it starts working as a hub. A sophisticate attacker may still be able to contaminate end stations - if he sends a gratuitous ARP reply to a station where he pretends he is the router (changes the MAC address), he will receive the traffic for the router and can also then make man-in-the-middle attacks (insert himself into forwarding chain of the station). More sophisticated solution is using 802.1x - port-based authentication - a switch will only start forwarding traffic to you once you authenticate and you of course shouldn't be able to authenticate as the server. On FreeBSD you can disable ARP and/or create static ARP entries and it will protect you a little but you also need to configure some protection on the network infrastructure. It's quite a complex issue to protect against this type of attack and I am no real guru so please take what I said with a grain of salt. HTH Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: terrible performance in 6.1beta4
Miguel wrote: .. postgresql is slow for me and others wrote: ... you may have to dedicate more memory to it Sorry for the above, but I haven't seen the beginning of the thread. I don't know PostgreSQL much but I also has been recently running quite simple program on one quite large table (2 milions of rows) and was trying to tune it. I haven't benchmarked anything (only that it was several orders of magnitude faster to run it on much bigger machine (2x2.8G Xeon, 2GB RAM, 10/15kRPM SCSI disks vs. 1xP4 Celeron 2.4G, 256MB RAM and an IDE disk)). I did the tuning after reading a little on the Net but the _POSSIBLY_IMPORTANT_ message I found was that PostgreSQL is a little different to other DB engines that it normally doesn't eat comparatively much memory even on loaded system because the developers believe that when a data set is much bigger than available memory (usual for big databases) it doesn't make sense to cache much in the DB engine because the OS can do it too and you can save memory... Above is the core of what I wanted to say - PostgreSQL process size was quite small (~100MB) on the bigger machine yet I think I tuned it according to the recommendations and that it is probably expected and correct with PostgreSQL. After comparing my config file to yours I see some differences: I have set some limits lower than you (shared_buffers 65536 vs. 1, work_mem 83886 vs. 1) and one higher (max_fsm_pages 2 vs. 10). I suspect that the main difference in our configs is fsync setting though. I have fsync = off and you the default (on). This may be very important difference, maybe similar to MySQL's innodb_flush_log_at_trx_commit (which, when set to 2, raises the performance of MySQL with InnoDB on FreeBSD significantly). I seem to remember that I read somewhere that fsync is pretty expensive on FreeBSD in comparison to Linux (because they cheat, as usual :-)) so maybe you can give it a try on your PostgreSQL too. It probably is a little dangerous though. HTH Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: again canon printer trouble
[EMAIL PROTECTED] wrote: Michal Mertl wrote: [EMAIL PROTECTED] wrote: Ok, two short questions. -Is someone able to translate this for me (seems to be Czech)? http://www.abclinuxu.cz/hardware/show/65412;jsessionid=10vmgmw8u8l16 -May my problem be due to acpi in any way? I don't know acpi either. But may try something like debug.acpi.disabled=isa in /boot/device.hints. Good or bad idea ? Hello. I am Czech. The page talks about using the printer under Linux. Canon provides drivers for it. I don't know if they can be used because I don't know the CUPS much. If the driver/filter program is (can be) invoked manually, you could probably use it with FreeBSD native CUPS. If not you can possibly run Linux CUPS and print to it even from FreeBSD native applications. If the program directly communicates with the printer you may be out of luck because you don't run Linux kernel and the emulation may not be complete in these low-level areas. I didn't see your original post but printing issue can not be caused by ACPI unless the interface for printing doesn't work at all. If for example you use USB connection to the printer and something else USB works, than ACPI can't be at fault. HTH Michal Hi Michal, Definetely this ML should be read at least by czech people. Others are welcome for sure. Thanks a million for your translation and re-explanation. I am going to test in that way tomorrow. Of course, I still do not understand why I cannot print directly with /dev/lpt0. I have never tried this but I believe it should work. You have to know how to talk to your printer, usualy using some language like Postscript or PCL or some vendor special language for modern ink printers. About acpi, I told that because I have ppc0: Standard parallel printer port port 0x378-0x37f irq 7 on acpi0 in dmesg and all the examples I saw had isa instead of acpi. Any idea? Is it normal? I think that the old reports were from older FreeBSD version which didn't have ACPI or from old machines which didn't have lpt in ACPI. Nowadays on acpi0 is pretty common. Thanks again Michal. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quotas + jail ?
Vladimir Dvorak wrote: Hello, I have simple question - is possible to use quotas in jail(8) environment ? Yes, it is, although with some restrictions. You have to enable the disk quotas from the host (have them listed in host's /etc/fstab). To operate the quotas from inside the jail quotas have to be mentioned in jail's /etc/fstab too (when using the file name of quota file it has to be relative to jail's root). Repquota/edquota/quota work inside the jail. You have to keep in mind that disk quotas are in fact a property of a filesystem and are not related to jails at all. So if two jails share a filesystem the disk quotas are shared too. If you have users with the same UID in both the jails they will share the quota. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: quotas + jail ?
Marc G. Fournier wrote: On Wed, 11 Jan 2006, Michal Mertl wrote: Vladimir Dvorak wrote: Hello, I have simple question - is possible to use quotas in jail(8) environment ? Yes, it is, although with some restrictions. You have to enable the disk quotas from the host (have them listed in host's /etc/fstab). To operate the quotas from inside the jail quotas have to be mentioned in jail's /etc/fstab too (when using the file name of quota file it has to be relative to jail's root). Repquota/edquota/quota work inside the jail. You have to keep in mind that disk quotas are in fact a property of a filesystem and are not related to jails at all. So if two jails share a filesystem the disk quotas are shared too. If you have users with the same UID in both the jails they will share the quota. How hard would it be to extend quotas so that its not just uid/gid based, but directory? ie. everything under /vm/jail1 falls under this quota, regardless of uid/gid? I don't think I understand your goal. Do you want some grand limit for whole jail's disk usage or have separated quotas for jails on the same partition? Neither can be done at the moment with disk quotas. The needed changes to support either will be quite extensive I believe. I recommend using separate partition for each jail. This will allow you to achieve both goals at the same time. If you have lot of jails and the number of partitions is the problem you can use gpt(8) or vnode based md(4) (see mdconfig(8)). With md(4) you can also use sparse backing files and that way have more space than you have on physical drives. Beware of overcommit though - I wouldn't be surprised if the system crashed when the disk is full and the md(4) file system is supposed to have free space in it. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gmirror dump device does not exist?
Nick Pavlica wrote: All, I have just set up a FBSD6.0 server configured with gmirror/raid1 using two SATA drives ad4 ad6 according to these instructions: http://www.onlamp.com/pub/a/bsd/2005/11/10/FreeBSD_Basics.html Everything is functioning properly with the exception of a boot warning that indicates that a dump device does not exist. I'm sure that I just missed something simple during the setup procedure. Does anyone have the quick fix for this? It is not possible to dump kernel to gmirror. The reason is that at the time, when the kernel is dumping core, it is usually in pretty bad state, kernel internals may be corrupted and so on. The dumping code is therefore written to be quite low level so that even wedged kernel can be dumped. The dumping code is part of hard disk controller's drivers. The gmirror is quite high-level device and geom itself needs working scheduler so there will probably never be a way to dump on gmirror provided swap. When the dumpon command is issued the check is performed whether the driver for the disk you want to dump on supports kernel core dumps. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipnat and ping problem.
Maślanka Wojciech píše v pá 23. 12. 2005 v 23:07 +0100: This is my network: Internet---[rl0, 192.168.0.50_10.0.0.1 ,rl1]--[10.0.0.2] On 10.0.0.2 machine I cant ping any host in internet. I can ping only 10.0.0.1 and 192.168.0.50. :( Whats wrong?? [/usr/src]#uname -a FreeBSD freebsd.mila10.6 6.0-RELEASE FreeBSD 6.0-RELEASE [/usr/src]#ipfstat -io pass out quick all pass in quick all [/usr/src]#ipnat -l List of active MAP/Redirect filters: map rl0 10.0.0.0/24 - 192.168.0.50/32 proxy port ftp ftp/tcp map rl0 10.0.0.0/24 - 192.168.0.50/32 portmap tcp/udp auto map rl0 10.0.0.0/24 - 192.168.0.50/32 You need also map rl0 10.0.0.0/24 - 192.168.0.50/32 icmpidmap icmp 64000:65535 In the documentation of ipnat(5) there's written that for this to reliably work you have to recompile the world with limited PID_MAX but it works without it. List of active sessions: MAP 10.0.0.2 3610 - - 192.168.0.508666 [66.249.85.83 80] MAP 10.0.0.2 3609 - - 192.168.0.508665 [66.249.85.83 80] MAP 10.0.0.2 3608 - - 192.168.0.508664 [66.249.85.19 80] MAP 10.0.0.2 3607 - - 192.168.0.508663 [194.204.152.34 53] MAP 10.0.0.2 3606 - - 192.168.0.508662 [66.249.85.83 80] Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath driver within 5.4-RELEASE
Glyn Tebbutt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew L. Gould wrote: On Tue, 16 Aug 2005 13:36:14 -0500 Nikolas Britton [EMAIL PROTECTED] wrote: On 8/16/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi I just wanted to know if the ath driver is included within the 5.4- RELEASE as I can't seem to find it with the GENERIC config or do I just load auth with kldload ? I can't check as I'm not at home atm. Thanks in advance Glyn Yes it's part of 5.4, started life in 5.2, man ath: http://www.freebsd.org/cgi/man.cgi?query=athapropos=0sektion=0manpath=FreeBSD+5.4-RELEASE+and+Portsformat=html http://www.freebsd.org/cgi/man.cgi The ath driver is available in 5.4 RELEASE; but is not compiled into the GENERIC kernel. If my memory serves me correctly, people on this list have reported problems loading the kernel modules. Therefore, you'll probably need to recompile the kernel with the following: device ath device ath_hal Regards, Andrew Gould ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Thanks for your replies guys. Will this support 11g as I read something about the wireless stack in 6.0 is different in some way compared to 5.4 ? I tried to compile 6.0-BETA 2 with both device ath and device ath_hal but the kernel compile died with undefined symbol error's, i've google it but not found anything, any idea's guy's ? I don't know if 5.4 supports 11g but it I know it doesn't support too much advanced authentication mechanisms (WPA). I believe you need not only ath and ath_hal in the kernel config file but also wlan and some ath_rate module (one of ath_rate_onoe, ath_rate_amrr or ath_rate_sample). The recommended rate module is ath_rate_sample. Why do you compile the modules statically into the kernel? Modules should work too. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath driver within 5.4-RELEASE
Glyn Tebbutt wrote: Michal Mertl wrote: I don't know if 5.4 supports 11g but it I know it doesn't support too much advanced authentication mechanisms (WPA). I believe you need not only ath and ath_hal in the kernel config file but also wlan and some ath_rate module (one of ath_rate_onoe, ath_rate_amrr or ath_rate_sample). The recommended rate module is ath_rate_sample. Why do you compile the modules statically into the kernel? Modules should work too. My other cards on linux dont support WPA yet anyway so I'm using WEP atm (yes I know its crappy and insecure:() I'm new to freebsd so im not exactly sure how everything works yet, so the kernel config builds all the stuff you need into the kernel but modules for everything else is still compiled? Yes. By default all the modules are always compiled and installed (in /boot/kernel/*.ko). because on my 6.0-BETA 2 ath module doesn't exists :? so in theory which module's do I need to load Modules for network cards are called if_$cardname(.ko). So to load ath(4) support you'd issue 'kldload if_ath'. The linker loads whatever other modules are required for function of the module which aren't compiled in or already loaded (so ath would load wlan, ath_rate and ath_hal). Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: any ipf wizards out there?
Gary Kline wrote: Folks, A couple weeks ago I realized that my ipf ruleset was messing up my web access ... ad had been for months I just tried an older, simpler ipf.rules. Same results. Can anybody out there in FreeBSD-land clue me in please? Without any concrete information it's hard to guess. The only thing I can think of is that you don't allow outgoing ICMP packet-too-big. This will make it for users with small MTU (e.g. some dial-up, PPPoE (ADSL) impossible to receive bigger pages (longer then their MTU minus something). gary ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: inbound ssh ceased on 4 servers at same time
John Brooks wrote: sshd is running on the affected machines no errors on console or logs, just times out waiting for the password prompt. interestingly: when investigating this at the console, attempting ssh sessions from the db server and backup server to the file server (these two are 'deeper' in the network so there was never an occasion to ssh FROM them before) produced the std warning about an unknown host prompting for inclusion in the ~/.ssh/known_hosts file. dns is not really involved, the ssh session is sent to the ip address directly as in ssh [EMAIL PROTECTED] With SSH a host name lookup is always involved. The server performs reverse and forward lookup on the connecting IP. I've recently also had problem with SSH and it was DNS issue. A good test if a daemon is running is connecting with telnet to its port - you can see three kinds of responses - connection reset (refused) on a closed port (nothing listens on this port), nothing (just message 'Trying...' - on non-existent/firewalled host/port) and established connection (telnet says 'Connected to...'). If you get 'Connected' with ssh and nothing is displayed it's in 99% of cases a DNS issue. If you get some message or the server just disconnects you (you get 'Connection closed' message) it might be tcpwrappers' decision (man 5 hosts_access). If you happen to have intermittent DNS issues you might better put the important hosts into /etc/hosts which is by default queried before the DNS servers. The other daemons working need not to mean much - they may not do a reverse DNS lookup on connecting IP. ping works in both directions as does all other network services (internal mysql, intranet http, pop3, smtp, smbd, nmdb, dns). network hardware and cabling issues have been effectively ruled out. -- John Brooks [EMAIL PROTECTED] -Original Message- From: Glenn Dawson [mailto:[EMAIL PROTECTED] Sent: Saturday, June 04, 2005 2:56 PM To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org Subject: Re: inbound ssh ceased on 4 servers at same time At 09:05 AM 6/4/2005, you wrote: Yesterday at about noon, all four freebsd servers on a clients lan quit accepting ssh connections. All were running 4.11-release-p4, and had been cvsup'd at the same time from cvs-10, cvs-11, or cvs-12. Outbound ssh (from console of the affected boxes) works as expected, both to local openbsd boxes and to remote locations. There are no host based firewalls involved, and all other network services are operating correctly. Netstat shows port 22 as listening. At 11:20 am (40 minutes earlier), ssh was working properly on all boxes. Has anybody encountered a situation like this before? Not specifically, but the first things I would check: is sshd running on the affected machines? when trying to connect to the affected machines, do the clients give any error messages? or does the connection just time out? are there any relevant entries in the log files on the affected machines? specifically /var/log/messages and /var/log/auth.log are the affected machines using the same name server? and if they are, can the affected machines do forward and reverse lookups for the IP of the system you are trying to connect from? -Glenn -- John Brooks [EMAIL PROTECTED] ___ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NTP issues with 5.4 (SOLVED)
I wrote: Hello, I run ntpd in daemon mode on several FreeBSD computers and synchronize with 'ntpd -q' all others. I've just updated one machine to 5.4 (from 5.3) and noticed the daemon was unhappy, often logging 'time reset' and resynchronizing with peers. On other machines I also only recently (after the upgrade to 5.4) see ntp problems - 'ntpd -q' gets stuck and time goes off. The machines were all fine before. I searched the web and archives and found some more people complaining about similar issues but I haven't found any good answer. At first I thought it was happening only on SMP computers but it isn't the case. The machines have all kinds of timecounters - ACPI-fast, ACPI-safe and i8254. I'd like to let you all know that I don't think the problem is as widespread as I originally thought. After tens of restarts of ntpd processes I've never experienced any problem synchronizing. No more hung 'ntpd -q' processes either. I suspect the latter was a consequence of my server having problems synchronizing. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Setting up ntpd on FreeBSD (5.4)
Benjamin Keating wrote: I'm running a generic install of FreeBSD 5.4 and would like to setup ntpd. ntpdate doesn't do me much good as I rarely reboot, but I took the handbooks suggestion of using it anyway (and I've verified it works)). Anyway, I'm having trouble setting up ntpd and it'd be great if I could get your input on my steps. I'd like for other machines on my network to talk to this one (ntpd server) to get the time rather then define each machine with it's own public ntpd servers. 1). Add ntpd_enable=YES to /etc/rc.conf 2). Create /etc/ntp.conf and (touch) /etc/ntp/ntp.drift /etc/ntp directory isn't used by default on 5.4. The default location for ntp.drift file is /var/db. I've never created it by hand (not even by 'touching' it), it gets created automatically. Permissions: /etc/ntp.conf-rw-r--r-- root:wheel /etc/ntp/ntp.drift -rw-r--r-- root:wheel %- BEGIN /etc/ntp.conf - restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap server clepsydra.dec.com server clock.fmt.he.net server clock.isc.org driftfile /etc/ntp/ntp.drift %- END /etc/ntp.conf - I rebooted and watched my /var/log/messages and saw: May 12 15:17:08 toki ntpd[349]: Frequency format error in /etc/ntp/ntp.drift I did a sockstat -l and you can see ntpd is running (BTW, is there anyway to have it not listen to for IPv6? I only use 4 and I hate seeing that clutter). I don't know. I run kernels without IPv6 so I only get a warning message it can't bind to IPv6. Have you searched the documentation in /usr/share/doc/ntp? After a quick search I haven't found anything but it well may be there. Some programs don't compile IPv6 support is NO_INET6 is defined (e.g. in /etc/make.conf) but ntp utilities' source doesn't contain the string so this wouldn't probably help either. What am I doing wrong? /etc/ntp/ntp.drift is writeable by root, which ntpd is running as... Im confused. Anyhelp would be greatly appreciated. Thanks - bpk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Setting up ntpd on FreeBSD (5.4)
Rob wrote: Michal Mertl wrote: /etc/ntp directory isn't used by default on 5.4. The default location for ntp.drift file is /var/db. I've never created it by hand (not even by 'touching' it), it gets created automatically. No, there's no such default as /var/db/ntp.drift. It's either /etc/ntp.drift or /var/db/ntpd.drift, depending on which of the two you consider is the 'most' default :). Sorry, I haven't actually checked my 'facts' before replying. It was because, as I wrote in my reply, the file gets created automatically and I don't change the defaults. I don't do it without a good reason. Sorry again for increasing the confusion. I hope it still helped the original poster. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: NTP issues with 5.4
Ted Mittelstaedt pe v st 11. 05. 2005 v 21:05 -0700: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michal Mertl Sent: Wednesday, May 11, 2005 3:59 PM To: Ted Mittelstaedt Cc: freebsd-questions@freebsd.org Subject: RE: NTP issues with 5.4 Ted Mittelstaedt wrote: Did you do an in-place update or a nuke-and-repave update? if it's an in-place update, then do a nuke-and-repave on your test system and see if the problem still happens. If not then there's a library or something somewhere that the updater forgot about. It update with buildworld and mergemaster. I doubt the issue can be cause by something in my config or installation. By 'nuke-and-repave' you mean fresh install? I can't do that on the machines in question, one of them is acting as a router. Then go to Goodwill and buy a $10 PC and load 5.4 on it. Your making excuses. If you have that many production systems that you just can't turn off, then you damn well better have a test system. Please calm down and don't order me what to do. I have been doing upgrades from source for ages and never had a problem. It is a documented process and I only upgraded some of the computers from 5.3 to 5.4, e.g. not across major versions. I believe the chance it's caused by borked installation is minimal - what do you think influences ntpd? It's linked to 4 libraries, all of them are updated, it doesn't use any system config files and there was only a slight change in imported ntp version. It can be caused by bad config of ntpd which only recently began to matter or more probably by a kernel change. I will try to boot with 5.3 kernel. I'll also try to see if I can reproduce it on some computer which I can try fresh install on. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NTP issues with 5.4
Rob pe v t 12. 05. 2005 v 07:47 -0700: Michal Mertl wrote: I have been doing upgrades from source for ages and never had a problem. It is a documented process and I only upgraded some of the computers from 5.3 to 5.4, e.g. not across major versions. I'm running 5-Stable, and each time I restart my router/gateway/server (also ntpd server), I have trouble getting the ntpd server operate properly. I still haven't figured out what's going wrong. Somehow ntpd can't access the external servers; during that time it will also refuse to be the server to my local network (so also the PCs on my local network are in ntpd trouble). After some time (hours or days) it seems to work suddenly, like magic. No, no, it's not that time is off to much. All PCs involved here are running approximately the correct time; at most 10 seconds off. However, I noticed something strange this week: I again had rebooted my router/server and the ntpd was 'out-of-order', as usual. I ran tcpdump on the external internet interface to monitor the activity on port 123, and I noticed something strange. My ntpd server was initializing itself by sending out udp requests not from port 123, but from a high port number, like this for example: my.gate.way:5045 ext.ntp.server:123 ext.ntp.server:123 my.gate.way:5045 So my server was sending udp request from the high port number to the ntp server on port 123. The ntp server then answered the udp request from port 123 to the high number port on my server. Because my firewall allows ntp/udp communication only via port 123, this communication was blocked. I guess this was causing my ntpd server to hang kind of indefinitely. When I opened up my firewall, the ntpd server suddenly made contact and all was fine. A little later, I ran the same tcpdump again, and found out that now both, my gateway/server and the external ntp server, were communicating via port 123. So I switched my firewall on again, and ntpd was still very happy, because now the ntp/udp communication went all via port 123. Hm. This is not my case. I've got firewalls configured too, but they allow this kind of traffic too. And I don't have them on all the computers I experience the problems either. Once ntpd was running for some time on the gateway, it suddenly started to function as a server to my local network; there is some delay here as if the ntpd server on my gateway has to stabilize some time first. Any comments to this? Some time is always needed before NTPD server responds to client queries AFAIK. I've just tried restarting the daemon and have been checking when it starts answering. It took about 5 minutes. When you issue sysinfo command from ntpdc you should see system peer set to something other than 0.0.0.0. My gateway is a production server, so I can't do too many experiments with rebooting the system ;(. Regards, Rob. Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
NTP issues with 5.4
Hello, I run ntpd in daemon mode on several FreeBSD computers and synchronize with 'ntpd -q' all others. I've just updated one machine to 5.4 (from 5.3) and noticed the daemon was unhappy, often logging 'time reset' and resynchronizing with peers. On other machines I also only recently (after the upgrade to 5.4) see ntp problems - 'ntpd -q' gets stuck and time goes off. The machines were all fine before. I searched the web and archives and found some more people complaining about similar issues but I haven't found any good answer. At first I thought it was happening only on SMP computers but it isn't the case. The machines have all kinds of timecounters - ACPI-fast, ACPI-safe and i8254. Do you have any idea? Michal Mertl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: NTP issues with 5.4
Ted Mittelstaedt wrote: Did you do an in-place update or a nuke-and-repave update? if it's an in-place update, then do a nuke-and-repave on your test system and see if the problem still happens. If not then there's a library or something somewhere that the updater forgot about. It update with buildworld and mergemaster. I doubt the issue can be cause by something in my config or installation. By 'nuke-and-repave' you mean fresh install? I can't do that on the machines in question, one of them is acting as a router. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michal Mertl Sent: Wednesday, May 11, 2005 3:37 PM To: freebsd-questions@freebsd.org Subject: NTP issues with 5.4 Hello, I run ntpd in daemon mode on several FreeBSD computers and synchronize with 'ntpd -q' all others. I've just updated one machine to 5.4 (from 5.3) and noticed the daemon was unhappy, often logging 'time reset' and resynchronizing with peers. On other machines I also only recently (after the upgrade to 5.4) see ntp problems - 'ntpd -q' gets stuck and time goes off. The machines were all fine before. I searched the web and archives and found some more people complaining about similar issues but I haven't found any good answer. At first I thought it was happening only on SMP computers but it isn't the case. The machines have all kinds of timecounters - ACPI-fast, ACPI-safe and i8254. Do you have any idea? Michal Mertl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Server-based address book with LDAP
darren david wrote: Hi all- So having sold my Mac (boo!) and being stuck with FreeBSD (yay!), I'm looking for a server-based address book replacement. LDAP seems like the way to go, but i have yet to find a good HOWTO and/or GUI based application for administering said contact repository. I'd ultimately like to be able to wire up a lightweight web-based solution for browsing addresses remotely, but first i need to get LDAP off the ground. If i ever get a Mac again, i'd likely use the new Auto LDAP-sync features in Tiger's Address Book, but for now, can anyone point me in the right direction? I found the page http://www.feldt.com/work/projects/openLDAP/ very usefull when setting up shared addressbook with OpenLDAP. The only mail client which can correctly authenticate against OpenLDAP and can insert/change records is AFAIK Evolution which works well on FreeBSD. thanks in advance, darren david ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT
Jay O'Brien wrote: Michal Mertl wrote: Didier Wiroth wrote: Hi, I'm using freebsd 5.4-prerelease on my laptop. My laptop has an ati mobility radeon 9600. Unfortunately it has very poor console vesa support. SC_PIXEL_MODE does not work, 90x60 is the highest resolution I can get for now. It looks like I'm not the only one having this problem with ati chipsets: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1091839+1096057+/usr/local/w ww/db/text/2005/freebsd-questions/20050123.freebsd-questions I saw this posting: http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035621.ht ml Unfortunately I'm not a programmer and have no ... to very poor patching skills. It looks to me, that in this posting(s) a few patches are grouped together to enable vesa 1024x768. 1) Has someone applied this patches? 2) As the patch(es) is/are on the entire page, I don't know how to separate them. Would someone mail me as an attachment the different patches and tell me how I should apply them: for example, mail me patch1, patch2, patch3 and the explanation how to patch them: cd /usr/src patch ~/patch1 patch ~/patch2 ...etc I think the newest and probably best (?) patch was prepared by Xin Li ([EMAIL PROTECTED]) who is also committer. I sent this email to him (or she? - sorry about that) in case he has some comments. Beware that he said he experienced some problems with previous version of the patch. I haven't tested this version of the patch myself but it at least compiles. It's available at http://people.freebsd.org/~delphij/vesa/ in files syscons.diff.20050215 and vidcontrol.diff.20050215 You would apply them with: cd /usr/src/sys/dev/syscons patch /path/syscons.diff.20050215 cd /usr/src/usr.sbin/vidcontrol patch /path/vidcontrol.diff.20050215 make clean make all make install You need also to rebuild and reinstall the kernel. You must have 'options SC_PIXEL_MODE' in your kernel config. You also need to have VESA available - you can load it with kldload vesa or include it in the kernel with 'options VESA'. After reboot with the new kernel you should be able to get list of all VESA and standard modes your card support with 'vidcontrol -i mode'. To be able to use them as your console mode you need to have the appropriate font loaded. The font resolution is seen in vidcontrol output in the 'font' column. To load the font 8x8 you can use 'vidcontrol -f /usr/share/syscons/fonts/cp437-8x8.fnt' or similar. To set the mode use 'vidcontrol MODE_$num' where $num is the mode number (first column in 'vidcontrol -i mode' output). HTH Michal I feel like I am missing a lot here. I want to display 132 characters per line on my console. I am not running X Windows and it is not a notebook. It doesn't matter. I only saw the most complaints from notebook owners who didn't have text mode console covering all LCD surface. I am running 5.3-RELEASE-p5 #0. What is this SC_PIXEL_MODE and where may I find documentation on it? I don't find it in /usr/src/sys/i386/conf/NOTES. man syscons(4). It's also mentioned in NOTES although not the NOTES you were looking at. Don't forget that on 5.x there are two conf directories - one platform independent in /sys/conf and other in /sys/$ARCH/conf. Common (platform independent) options like this one are in /sys/conf/NOTES. To rebuild and reinstall the kernel, after editing my /usr/src/sys/i386/conf/GENERIC to insert 'options SC_PIXEL_MODE', would I 'make buildkernel' and then 'make installkernel' or is there something else I'm missing? No, that's the way to do it. I note that some of the messages are posted to multiple mailing lists, and I suspect that as I only read [EMAIL PROTECTED] I'm not seeing the entire story. I'm afraid that's quite possible. Please go search the archives. Jay O'Brien Rio Linda, California USA Michal Mertl Prague, Bohemia, Czech Republic :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT
Jay O'Brien wrote: Michal Mertl wrote: I feel like I am missing a lot here. I want to display 132 characters per line on my console. I am not running X Windows and it is not a notebook. It doesn't matter. I only saw the most complaints from notebook owners who didn't have text mode console covering all LCD surface. I am running 5.3-RELEASE-p5 #0. What is this SC_PIXEL_MODE and where may I find documentation on it? I don't find it in /usr/src/sys/i386/conf/NOTES. man syscons(4). It's also mentioned in NOTES although not the NOTES you were looking at. Don't forget that on 5.x there are two conf directories - one platform independent in /sys/conf and other in /sys/$ARCH/conf. Common (platform independent) options like this one are in /sys/conf/NOTES. Thanks! Now that I see that it is perhaps not required for my system, that is not a laptop, is it possible that I don't need this at all? Is it definitely needed to support 132 character terminal mode, or is just needed for laptops? There's no standard VGA 132 character text mode. It's either provided by VESA or emulated using some graphics mode. Newer graphics hardware stopped supporting extended text modes. If you want such modes you need to emulate them (render the characters using lots of small dots instead of just writing characters to the adapter which renders them for you). Support for this functionality is included in syscons/vga driver when you define options SC_PIXEL_MODE. Standard FreeBSD supports only planar graphics mode 800x600 dots with 4 bits (16) of color information per pixel which can be run on old plain VGA with 256KB of memory. The patches we are talking about add support for rendering the characters in any graphics mode your card supports (through VESA) with = 15 bits per pixel. You could then run say 1600x1200x32 bpp (16milions of colours) for a text mode console. You can't use any graphics there but the textual resolution will be bigger. There also isn't support for using simultaneously more than 16 (or is it 15?) different colors for characters even when milions are technically possible. It is wonderful to be a part of a caring community that spans the world, without concern for international borders. Fortunately for me, everyone uses english; I'm stuck with only one language (plus international morse code, but that's another story). Yes, it really is great. Not the English though. I'd prefer Czech but I'm afraid it's a lost battle :-). Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT
Jay O'Brien pe v ne 10. 04. 2005 v 15:21 -0700: Michal Mertl wrote: There's no standard VGA 132 character text mode. It's either provided by VESA or emulated using some graphics mode. Newer graphics hardware stopped supporting extended text modes. If you want such modes you need to emulate them (render the characters using lots of small dots instead of just writing characters to the adapter which renders them for you). Support for this functionality is included in syscons/vga driver when you define options SC_PIXEL_MODE. Standard FreeBSD supports only planar graphics mode 800x600 dots with 4 bits (16) of color information per pixel which can be run on old plain VGA with 256KB of memory. The patches we are talking about add support for rendering the characters in any graphics mode your card supports (through VESA) with = 15 bits per pixel. You could then run say 1600x1200x32 bpp (16milions of colours) for a text mode console. You can't use any graphics there but the textual resolution will be bigger. There also isn't support for using simultaneously more than 16 (or is it 15?) different colors for characters even when milions are technically possible. Thanks for the explanation, it is appreciated. I tried the process and encountered errors. Here's what happened: patch /tmp/syscons.diff.20050215 this went fine. patch /tmp/vidcontrol.diff.20050215 returned errors as shown below: # patch /tmp/vidcontrol.diff.20050215 Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: vidcontrol.1 |=== |RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.1,v |retrieving revision 1.55 |diff -u -r1.55 vidcontrol.1 |--- vidcontrol.1 2 Mar 2003 21:04:21 - 1.55 |+++ vidcontrol.1 17 Jan 2005 05:27:25 - -- Patching file vidcontrol.1 using Plan A... Hunk #1 succeeded at 11. Hunk #2 succeeded at 88. Hunk #3 succeeded at 297. Hunk #4 succeeded at 532. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |Index: vidcontrol.c |=== |RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.c,v |retrieving revision 1.48 |diff -u -r1.48 vidcontrol.c |--- vidcontrol.c 13 Jan 2005 03:59:44 - 1.48 |+++ vidcontrol.c 17 Jan 2005 05:27:25 - -- Patching file vidcontrol.c using Plan A... Hunk #1 succeeded at 24. Hunk #2 succeeded at 48. Hunk #3 succeeded at 66 with fuzz 1. Hunk #4 failed at 187. Hunk #5 succeeded at 223. Hunk #6 failed at 239. Hunk #7 failed at 257. Hunk #8 failed at 297. Hunk #9 failed at 332. Hunk #10 succeeded at 348 with fuzz 2. Hunk #11 failed at 377. Hunk #12 failed at 419. Hunk #13 failed at 507. Hunk #14 failed at 572. Hunk #15 failed at 669. Hunk #16 failed at 722. Hunk #17 failed at 743. Hunk #18 failed at 806. Hunk #19 succeeded at 891. Hunk #20 failed at 900. Hunk #21 failed at 933. Hunk #22 succeeded at 950 with fuzz 2. Hunk #23 failed at 962. Hunk #24 failed at 985. Hunk #25 failed at 1035. Hunk #26 failed at 1050. Hunk #27 succeeded at 1148. Hunk #28 succeeded at 1173. Hunk #29 succeeded at 1217. Hunk #30 succeeded at 1234. 19 out of 30 hunks failed--saving rejects to vidcontrol.c.rej done Not being a c programmer, I can't understand what the vidcontrol.c.rej file is trying to tell me. It is a 29K file. As I recalled a previous email telling someone to go ahead anyway, I went ahead with make clean and that went ok. Then I did make all and here's the results: You haven't read the thread in the archives carefully enough, have you? Here is what I wrote (privately to the original poster but I explained the error to the mailing list too): What? I don't know how the patching of vidcontrol ended but you'd better redo it with fresh files from current. Go download vidcontrol.c v 1.48 and vidcontrol.1 from http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/vidcontrol/ Then run the patch on it again and recompile/reinstall vidcontrol binary. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT
Jay O'Brien wrote: Michal Mertl wrote: You haven't read the thread in the archives carefully enough, have you? Yes, but unfortunately I didn't comprehend. Here is what I wrote (privately to the original poster but I explained the error to the mailing list too): What? I don't know how the patching of vidcontrol ended but you'd better redo it with fresh files from current. Go download vidcontrol.c v 1.48 and vidcontrol.1 from http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/vidcontrol/ Then run the patch on it again and recompile/reinstall vidcontrol binary. I did that. The files are vidcontrol.1 Rev 1.55 and Vidcontrol.c Rev 1.48. Now all hunks failed. The results are below. I don't know. The text before the line starting with Patching is taken from the patch file. The patch program doesn't retrieve any files. So I think you either used bad files to patch or bad patchfile. You need to have the original files. To check they're correct you can use md5 utility. md5 vidcontrol.c MD5 (vidcontrol.c) = 1068e5a6aff863e2bc7a0c02098d43b1 md5 vidcontrol.1 MD5 (vidcontrol.1) = 080d2b84f2e3914090279fee6e5f2406 md5 vidcontrol.diff.20050215 MD5 (vidcontrol.diff.20050215) = 67ae12fe2a4fecae1bb7adb141efe021 You need to see the same strings. Then command 'patch /path/to/vidcontro.diff.20050215' must work. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any way to log all process launches?
Richard Morse wrote: On 8 Apr 2005, at 10:41 AM, Giorgos Keramidas wrote: On 2005-04-08 10:32, Richard Morse [EMAIL PROTECTED] wrote: Hi! I'm trying to track down an odd problem, for which it would be very useful to be able to have the computer keep track of every process that gets created -- ie, keep a list of every fork / exec that occurs. Is this possible? Yes, it is possible. This is part of what `process accounting' does. Look at the manpages of accton(8), lastcomm(1); then check the accounting_enable knob in rc.conf(5) and /etc/defaults/rc.conf Thanks! I was looking under logging and auditing and tracing -- not accounting... If you need more detailed information some patches at garage.freebsd.pl might be interesting - especially lrexec. It may be a bit outdated but it provides you with the information standard utilities don't. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any way to log all process launches?
markzero pe v p 08. 04. 2005 v 19:44 +0100: If you need more detailed information some patches at garage.freebsd.pl might be interesting - especially lrexec. It may be a bit outdated but it provides you with the information standard utilities don't. Michal Thanks for the interesting link. How much of this is committed to the tree (perhaps -CURRENT)? Quite a few of those patches seem to provide zero-cost security (like the setgid crontab) and I for one would certainly like to see them in FreeBSD in the future... Not much. His GEOM modules, jailfsstat and kern.msgbuf in some form or other as far as I can tell. The author of the patches became FreeBSD committer so you'd better ask him. Lot's of people would love to see some more it the tree. I like and would use mijail and privipc for sure. There were some discussions about the patches on the mailing lists in the past. E.g. everyone likes the idea of privipc but it seems to be almost impossible to do really correctly. Try to ask [EMAIL PROTECTED] Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT
Didier Wiroth wrote: Hi, I'm using freebsd 5.4-prerelease on my laptop. My laptop has an ati mobility radeon 9600. Unfortunately it has very poor console vesa support. SC_PIXEL_MODE does not work, 90x60 is the highest resolution I can get for now. It looks like I'm not the only one having this problem with ati chipsets: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1091839+1096057+/usr/local/w ww/db/text/2005/freebsd-questions/20050123.freebsd-questions I saw this posting: http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035621.ht ml Unfortunately I'm not a programmer and have no ... to very poor patching skills. It looks to me, that in this posting(s) a few patches are grouped together to enable vesa 1024x768. 1) Has someone applied this patches? 2) As the patch(es) is/are on the entire page, I don't know how to separate them. Would someone mail me as an attachment the different patches and tell me how I should apply them: for example, mail me patch1, patch2, patch3 and the explanation how to patch them: cd /usr/src patch ~/patch1 patch ~/patch2 ...etc I think the newest and probably best (?) patch was prepared by Xin Li ([EMAIL PROTECTED]) who is also committer. I sent this email to him (or she? - sorry about that) in case he has some comments. Beware that he said he experienced some problems with previous version of the patch. I haven't tested this version of the patch myself but it at least compiles. It's available at http://people.freebsd.org/~delphij/vesa/ in files syscons.diff.20050215 and vidcontrol.diff.20050215 You would apply them with: cd /usr/src/sys/dev/syscons patch /path/syscons.diff.20050215 cd /usr/src/usr.sbin/vidcontrol patch /path/vidcontrol.diff.20050215 make clean make all make install You need also to rebuild and reinstall the kernel. You must have 'options SC_PIXEL_MODE' in your kernel config. You also need to have VESA available - you can load it with kldload vesa or include it in the kernel with 'options VESA'. After reboot with the new kernel you should be able to get list of all VESA and standard modes your card support with 'vidcontrol -i mode'. To be able to use them as your console mode you need to have the appropriate font loaded. The font resolution is seen in vidcontrol output in the 'font' column. To load the font 8x8 you can use 'vidcontrol -f /usr/share/syscons/fonts/cp437-8x8.fnt' or similar. To set the mode use 'vidcontrol MODE_$num' where $num is the mode number (first column in 'vidcontrol -i mode' output). HTH Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re : Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT
Didier Wiroth wrote: Hello, Thank you very much for replying. cd /usr/src/usr.sbin/vidcontrol patch /path/vidcontrol.diff.20050215 I'm using the RELENG_5 sources from today. The syscons.diff.20050215 works but the vidcontrol.diff.20050215 gives some errors. The diff is against the sources from -CURRENT where it applies and compiles cleanly. You should be ok using the current vidcontrol sources on -STABLE. The only difference is just some code purity fixes by Xin Li - probably in preparation for integrating the changes we speak about. Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drm/dri/glxinfo on 6-current xorg 6.8.2 with radeon 9200
Randy Primeaux wrote: Hi, I'm having trouble getting DRI direct rendering enabled. I had it enabled in October, however since then I've upgraded everything but my video card. The earliest point where I can find a failure report is in Xorg.0.log: (EE) RADEON(0): [drm] Failed to map vertex/indirect buffers list I believe the problem was caused by a major changes in the tree and a bug in DRM which was exposed by them. DRM was crippled on Feb 22. It was fixed on Apr 10. Try with newer CURRENT and I believe it will work for you again. You really only need a new kernel. HTH Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT
Didier Wiroth wrote: Unfortunately with patch applied it does not compile on stable: Warning: Object directory not changed from original /usr/src/usr.sbin/vidcontrol cc -O -pipe -c vidcontrol.c vidcontrol.c: In function `video_mode': vidcontrol.c:500: error: `_VESA_800x600_DFL_COLS' undeclared (first use in this function) vidcontrol.c:500: error: (Each undeclared identifier is reported only once vidcontrol.c:500: error: for each function it appears in.) vidcontrol.c:505: error: `_VESA_800x600_DFL_FNSZ' undeclared (first use in this function) vidcontrol.c:509: error: `_VESA_800x600_DFL_ROWS' undeclared (first use in this function) *** Error code 1 I believe Didier used broken vidcontrol.c file. The patch was for current and needs to be applied to clean vidcontrol.c ver 1.48. It works for me (on CURRENT anyways). Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD's pf and traffic
Eugene M. Minkovskii pe v ne 20. 03. 2005 v 12:31 +0300:
Hello!
Does any body know, how can I use OpenBSD's pf (packet filter) for
determine total traffic volume on network interface? If it's
impossible, what facility you recommend me to do this?
I don't know much about pf, but I use ipfw and /usr/ports/sysutils/ipa
for the purpose. Works very well for me. IPFW itself has counters but
ipa makes the stats persist across reboots and changes to the ruleset.
Be carefull not to reconfigure ipfw from under running ipa - it will
think the counters overflowed and add huge numbers to the last known
value. Additionally ipa can do much more than just simple counters.
I configure it like this:
ipfw:
100 add allow all from any to any in via xl0
110 add allow all from any to any out via xl0
ipa(/usr/local/etc/ipa.conf):
rule xl0-in {
ipfw = 100
info = Incoming traffic for xl0
}
rule xl0-out {
ipfw = 110
info = Outgoing traffic for xl0
}
HTH
Michal Mertl
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone running Trend Micro IWSS in linux-compat mode?
David Landgren wrote: Hello List, I'm running a squid proxy on FreeBSD. The big problem today is web-borne viruses, spyware and other crap. The general feeling on the Squid users mailing list is that Trend Micro's InterScan Web Security Suite product is the way to go. Having looked at the various incomplete, non-functional free offerings, I have no problem going with a commercial product. The trouble is, they only offer it on Windows, Linux and Solaris. I like apache + mod_clamav. Unfortunately from reading Apache changelogs I decided to go with 2.1-alpha and had to modify mod_clamav to fit there. I sent my modifications to mod_clamav author who said he'll probably incorporate most of it in the next release. They were pretty big and in addition to making mod_clamav work with 2.1 they fixed some real bugs (and probably added some). I can send you what I have. Michal Mertl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
