vnet & firewalls in 12.0
Wanting to get a head start on using 12.0 and vnet jails with in jail firewall. 1. Will Vimage be compiled as a module in the 12.0 kernel and be included in the base system release? 1.a. Has the boot time console log message about vimage being "highly experimental" been removed? 2. Has the pf firewall been fixed so it can now run in a vnet jail or multiple vnet jails with out concern for which firewall is running on the host? 2.a. Is each vnet/pf log only viewable from it's vnet jail console? 2.b. Will pf/kernel module auto load on first call from a vnet jail? 2.c. Does vnet/pf NAT work? 3. Does the ipfw firewall still have the 11.x release mandatory requirements that the host must also be running ipfw for the vnet jailed ipfw to work? 3.a. Are all vnet/ipfw log messages still intermixed with the host's ipfw log messages? 3.b. Does vnet/ipfw NAT work? 4. Has any work been done to ipf (ipfilter) so it will function when used in a vnet jail? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-BETA1 vt console with rc.conf blanktime, screensaver or loader.conf splash screen not working.
blanktime, screensaver has no effect on vt console. splash screen has no effect on vt console. no messages of any kind issued. They all work on sc console. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-BETA1 vnet with pf firewall
Tested with host running ipfilter and vnet running pf. Tried loading pf from host console or from vnet console using kldload pf.ko command and get this error message; linker_load_file: /boot/kernel/pf.ko-unsupported file type. Looks like the 12.0 version of pf which is suppose to work in vnet independent of what firewall is running on the host is not working. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 12.0-BETA1 vnet with pf firewall
Bjoern A. Zeeb wrote: On 28 Oct 2018, at 15:31, Ernie Luzar wrote: Tested with host running ipfilter and vnet running pf. Tried loading pf from host console or from vnet console using kldload pf.ko command and get this error message; linker_load_file: /boot/kernel/pf.ko-unsupported file type. Looks like the 12.0 version of pf which is suppose to work in vnet independent of what firewall is running on the host is not working. You cannot load pf from inside a jail (with or without vnet). Kernel modules are global objects loaded from the base system or you compile the devices into the kernel; it is their state which is virtualised. If you load multiple firewalls they will all be available to the base system and all jails+vnet. Whichever you configure in which one is up to you. Just be careful as an unconfigured firewall might have a default action affecting the outcome of the overall decision. For example you could have: a base system using ipfilter and setting pf to default accept everything and a jail+vnet using pf and setting ipfilter there to accept everything. Hope that clarifies some things. /bz Hello Bjoern. What you said is correct for 10.x & 11.x. But I an talking about 12.0-beta1. I have the ipfilter options enabled in rc.conf of the host and on boot ipfilter starts just like it all ways does. Now to prep the host for pf in a vnet jail, I issue from the host console the "kldload pf.ko" command and get this error message; linker_load_file: /boot/kernel/pf.ko-unsupported file type. Something is wrong here. This is not suppose to happen according to your post above. Remember that in 12.0 vimage is included in the base system kernel. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-BETA1 vnet with pf firewall log problem
Running pf on host and in vnet jail. In the vnet jail rc.conf have normal parameters to start pf and the log. On vnet jail start up the vnet jail log specified in the jail(8) jail.conf file gets this error message. Startling pflog. Enabling pfpfctl: /dev/pf: No such file or directory pfctl: /dev/pf: No such file or directory Still have to test pf ftpproxy and pf NAT in a vnet jail. Is there some general thing I am missing here? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0 betaX with vnet.pf
Hello lists: With 12.0, vimage is now included with the system base kernel and the pfctl program has been worked on so it will function in a vnet jail. While 12.0 is still in the beta releases i am trying to test this new environment. All ready found bug dealing with ipfilter running on host with pf trying to be loaded. This bug is suppose to be fixed in beta3. Having trouble setting up a vnet jail with pf firewall. My setup = host running pf with pass all and log all rules on the interface facing the public internet. vnet jail has complete directory tree. pf is started by vnet jail's rc.conf pf option statements. pf rules use macro containing the epair2b as interface name. pflog needs devfs_ruleset to unhide pflog. use bridge/epair for networking. can ping 10.0.10.2 on host from vnet jail. Having these problems pf log inside of vnet jail not being populated pf nat rule causing rule set error can not ping public internet from vnet jail. ftpproxy rule error. Has anyone been able to get a 12.0 vnet/pf environment working? Would anyone be willing to help me get my setup working? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-BETA1 - vimage name
Issuing the kldstat -v command no longer shows the vimage name. Has it be renamed to something different? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-beta3 base.txz missing complete dir tree
ftp.freebsd.org/pub/FreeBSD/releases/amd/amd/12.0-BETA3/base.txz /usr/local empty /var/log empty This is really making testing imposable! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-RC3 vnet jail with pf firewall/NAT not working
Have gateway host, (ie; host that is connected directly to the public internet.) running a vnet jail that has pf firewall running inside of it. When I start the vnet jail I see a few dhclient tasks auto start for vge0 which is the interface added as member to the bridge. I take this to mean that the vnet jails external network is configured correctly. Can not ping 8.8.8.8 from the vnet jails console. I can see the pf rules are loaded. But the pf log shows no traffic at all. Think problem is with the nat rule syntax or the nat function of pf is non-functional. Can not reach the public internet using this nat rule nat pass on epair2b inet from 10.0.20.10 to any -> xx.xx.xx.xx 10.0.20.10 is ip address assigned to the vnet jail xx.xx.xx.xx is the ip address assigned to the host by the isp. Also tried this with no joy nat pass on epair2b inet from 10.0.20.10 to any -> epair2b Anyone been able to get pf NAT to work in a live vnet jail in this manner? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO - jails - FreeBSD 12 + VNET + ZFS
BulkMailForRudy wrote:
I love using jails. For many years, I used a tool to help out: ezjail,
now I am just raw-dogging it by using the config file in /etc/jail.conf
Here is my config:
# /etc/jail.conf
# VNET is used to send an epair to each jail.
# The epair is renamed jail0 with exec.created in each jail.
# exec.prestart Script creates bridge0 if needed.
# Global settings applied to all jails.
# haven't found a good reason to run a jail as NOT root
exec.system_user = "root";
exec.jail_user   = "root";
mount.devfs;
allow.raw_sockets;
devfs_ruleset    = "5";
# Networking and the exec cycle
$uplinkdev       = "ix0";
vnet;
vnet.interface   = "jail0";              # default
vnet interface
exec.prestart    = "ifconfig bridge0 > /dev/null 2> /dev/null || (
ifconfig bridge0 create up && ifconfig bridge0 addm $uplinkdev )";
exec.prestart   += "ifconfig $epair create
up                || echo 'Skipped creating epair
(exists?)'";
exec.prestart   += "ifconfig bridge0 addm
${epair}a          || echo 'Skipped adding bridge member
(already member?)''";
exec.created     = "ifconfig ${epair}b name
jail0Â Â Â Â Â Â Â Â Â Â Â Â || echo 'Skipped renaming ifdev to jail0'";
exec.clean;
exec.start       = "/bin/sh /etc/rc";
exec.stop        = "/bin/sh /etc/rc.shutdown";
exec.poststop    = "ifconfig bridge0 deletem ${epair}a";
#exec.poststop   += "ifconfig ${epair}a destroy";
# Per-jail settings
ns1 {
   path         = "/data/ns1.monkeybrains.net/";
   host.hostname = "ns1.monkeybrains.net";
   $epair       = "epair0"; # must be unique in every jail
}
tac {
   path         = "/data/tac.monkeybrains.net/";
   host.hostname = "tac.monkeybrains.net";
   $epair       = "epair1";
}
=
Here is a look at ifconfig before and after jail creation.
 Before jails start up
ix0: flags=8843 metric 0 mtu 1500
options=e53fbb
   ether ac:1f:6b:6a:14:78
   inet 10.1.2.3 netmask 0xff00 broadcast 10.1.2.255
   inet6 fe80::ae1f:::1478%ix0 prefixlen 64 scopeid 0x1
   inet6 2607:f598::a:a prefixlen 64
   media: Ethernet autoselect (1000baseT )
   status: active
   nd6 options=21
lo0: flags=8049 metric 0 mtu 16384
options=680003
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
   inet 127.0.0.1 netmask 0xff00
   groups: lo
ix0: flags=8943 metric 0
mtu 1500
options=a538b9
   ether ac:1f:6b:6a:14:78
   inet 208.69.40.26 netmask 0xff00 broadcast 208.69.40.255
   inet6 fe80::ae1f:6bff:fe6a:1478%ix0 prefixlen 64 scopeid 0x1
   inet6 2607:f598::d045:281a prefixlen 64
   media: Ethernet autoselect (1000baseT )
   status: active
   nd6 options=21
ix1: flags=8802 metric 0 mtu 1500
options=e53fbb
   ether ac:1f:6b:6a:14:79
   media: Ethernet autoselect
   status: no carrier
   nd6 options=29
lo0: flags=8049 metric 0 mtu 16384
options=680003
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
   inet 127.0.0.1 netmask 0xff00
   groups: lo
   nd6 options=21
bridge0: flags=8843 metric 0 mtu
1500
   ether 02:16:09:1c:af:00
   id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
   maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
   root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
   member: epair1a flags=143
           ifmaxaddr 0 port 6 priority 128 path cost 2000
   member: epair0a flags=143
           ifmaxaddr 0 port 5 priority 128 path cost 2000
   member: ix0 flags=143
           ifmaxaddr 0 port 1 priority 128 path cost 2000
   groups: bridge
   nd6 options=1
epair0a: flags=8943
metric 0 mtu 1500
   options=8
   ether 02:8d:76:e8:34:0a
   inet6 fe80::8d:76ff:fee8:340a%epair0a prefixlen 64 scopeid 0x5
   groups: epair
   media: Ethernet 10Gbase-T (10Gbase-T )
   status: active
   nd6 options=21
epair1a: flags=8943
metric 0 mtu 1500
   options=8
   ether 02:7a:d1:7c:f8:0a
   inet6 fe80::7a:d1ff:fe7c:f80a%epair1a prefixlen 64 scopeid 0x6
   groups: epair
   media: Ethernet 10Gbase-T (10Gbase-T )
   status: active
   nd6 options=21
 Start up jails
# service jail start
Starting jails: ns1 tac.
# ifconfig
ix0: flags=8943 metric 0
mtu 1500
options=a538b9
   ether ac:1f:6b:6a:14:78
   inet 10.1.2.3 netmask 0xff00 broadcast 10.1.2.255
   inet6 fe80::ae1f:::1478%ix0 prefixlen 64 scopeid 0x1
   inet6 2607:f598::a:a prefixlen 64
   media: Ethernet autoselect (1000baseT )
   status: active
   nd6 options=21
lo0: flags=8049 metric 0 mtu 16384
options=680003
   inet6 ::1 prefixlen 128
  Â
Re: RCTL and VIMAGE for 11.0-RELEASE
Bjoern A. Zeeb wrote: On 24 Aug 2015, at 19:08 , Mark Felder wrote: What is preventing RCTL from being enabled right now? Any known/serious blockers? It’s enabled in GENERIC. And the same for VIMAGE? I know there were issues with some firewalls, but I'm not sure where that stands today. Does it degrade network performance in a measurable way? Ignoring performance for a second, there is more than just firewalls that needs to be done. I started writing a plan for the next 4 months yesterday. Most of this was done a few years ago and never made it to HEAD. It needs to be re-validated. If my plan comes together we’ll have another 4 month window before the 11 release cycle will start. /bz It's been 5 months since the above was posted. What is the status of VIMAGE as part of base in 11.0-RELEASE? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Update to 11.0-RELEASE Schedule
Glen Barber wrote: As many are aware, one of the major user-facing changes to FreeBSD in 11.0-RELEASE is packaging the base system with pkg(8). Originally, the 11.0-RELEASE code slush was scheduled to start on April 22, 2016, which is only a week away at this point. With the packaged base system being such a major change to FreeBSD, and the project branch is not yet merged back to head, the 11.0-RELEASE schedule has been adjusted to push the release cycle back about a month. Anything less than a month for this code to settle in head is far too little time to allow wider testing, despite many people using the project branch and reporting problems (and thank you!). The updated schedule is available on the Project website at: https://www.FreeBSD.org/releases/11.0R/schedule.html Regarding the projects/release-pkg branch specifically, I am currently planning on merging it back to head on Friday, provided nothing serious is reported before then. Thanks. Glen On behalf of: re@ Is the VIMAGE revamp by "Bjoern A. Zeeb" completed and is it going to be included in 11.0? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
11.0-RELEASE pkg base & base.txz file
11.0 will have pkg base, thats ok, but what does than mean for the base.txz file? It it going to stay as part of FBSD install? I have many scripts for creating jails which depend on the base.txz file. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0-RELEASE pkg base & base.txz file
Slawa Olhovchenkov wrote: On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote: On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: On 04/18/16 10:00, Ernie Luzar wrote: 11.0 will have pkg base, thats ok, but what does than mean for the base.txz file? It it going to stay as part of FBSD install? I have many scripts for creating jails which depend on the base.txz file. It's even easier now: # mkdir -p /usr/jails/new # pkg -r /usr/jails/new install -r base -g '*' And where /etc now? What do you mean? At Jan 27 no package containing files from distributeworld. At Mar 02 r298107 change this? You have NOT answered the original question, what's going to happen to the base.txz file in 11.0? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
As long as packaged base is not mandatory, it is fine by me. +1 on that ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
console in 11.0-ALPHA4
I have installed 11.0-ALPHA4-i386-20160617-r301975. The console looks very different from all previous releases. I find it to be harder to read. This manifests it self with the boot log messages and the normal behavior of the virtual consoles. But the real problem is in the notable hesitation when switching between virtual consoles. From the boot log (ie: dmesg) I see this VT(vga): resolution 640x480 This must be what is making the console display so different from previous releases. Can VT be configured to default to present the same console behavior as previous releases before this version of 11.0 gets published as RELEASE? About the "hesitation when switching between virtual consoles" I am thinking that this reduced performance may be caused by WITNESS being enabled in the ALPHA series of releases. Can anyone verify that this hesitation will not exist in the published RELEASE? In the boot log I get this message 16 times. "vicontrol: setting cursor type: Inappropriate ioctl for device" They don't seem to cause any problems that I have stumbled across. Is anyone else getting these "NOTICE" type messages? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
11.0-ALPHA4 and VIMAGE
Hello list; I have installed 11.0-ALPHA4-i386-20160617-r301975 to test VIMAGE. I have read previous list posts saying vimage was going to be part of the base system in 11.0. When I configure a jail with vnet I get a error typical of vimage not being compiled into the kernel. To me it looks like vimage is not part of the base system in 11.0. What is the status of vimage in 11.0? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
Trond Endrestøl wrote: On Mon, 20 Jun 2016 11:36-0400, Ernie Luzar wrote: I have installed 11.0-ALPHA4-i386-20160617-r301975. The console looks very different from all previous releases. I find it to be harder to read. This manifests it self with the boot log messages and the normal behavior of the virtual consoles. But the real problem is in the notable hesitation when switching between virtual consoles. From the boot log (ie: dmesg) I see this VT(vga): resolution 640x480 This must be what is making the console display so different from previous releases. Can VT be configured to default to present the same console behavior as previous releases before this version of 11.0 gets published as RELEASE? If you want textmode like in the old days, add this line to /boot/loader.conf: hw.vga.textmode="1" You can also interrupt the final boot loader, and type: set hw.vga.textmode="1" Then type: menu or: boot About the "hesitation when switching between virtual consoles" I am thinking that this reduced performance may be caused by WITNESS being enabled in the ALPHA series of releases. Can anyone verify that this hesitation will not exist in the published RELEASE? The "hesitation" is sometimes hardware dependent. A GPU with a KMS driver makes it better. It's even worse in some virtualization environments, e.g. Microsoft Hyper-V. In the boot log I get this message 16 times. "vicontrol: setting cursor type: Inappropriate ioctl for device" They don't seem to cause any problems that I have stumbled across. Is anyone else getting these "NOTICE" type messages? If you decide to continue with the vt console, you should consider the following: With the new VT console in graphics mode, you don't need to load any fonts. Disable or remove any font lines from /etc/rc.conf. I haven't tried the vt console in text mode lately, so maybe you need the fonts in that case. Look for the appropriate keymap file in /usr/share/vt/keymaps/ and update the keymap line in /etc/rc.conf. Here's the Norwegian keyboard layout as an example: keymap="norwegian.iso" # Old Norwegian keymap for the sc console keymap="no"# New Norwegian keymap for the vt console On my 10.3-p4 system I added these 2 lines to loader.conf kern.vty=vt hw.vga.textmode=1 This change caused my 10.3 system to use "vt" and returned the console behavior look and feel to be just like the (sc(4) console. The "hesitation when switching between virtual consoles" also no longer happens. I think its a mistake to default the vt console driver to graph mode in 11.0. It should default to hw.vga.textmode=1 mode to be consistent with previous RELEASE versions of FreeBSD. I found the cause of this boot time message "vicontrol: setting cursor type: Inappropriate ioctl for device" In my rc.conf I had this statement vidcontrol -c blink -h 250 From testing it seems that vt does not handle the "blink" option for causing the cursor to blink. Is there a vt option to enable cursor blinking And while we are on fallout from vt becoming the default console driver in 11.0, what about the loader.conf options for "splash" screens and the rc.conf option screen saver "saver= " and the "blanktime= " option. Have these been reviewed? Now here is the real show stopper. My rc.conf has moused_flags="-m 2=3" to enable mouse copy and past. This function on longer works under vt mode. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
Ed Maste wrote: On 20 June 2016 at 14:29, Ernie Luzar wrote: I found the cause of this boot time message "vicontrol: setting cursor type: Inappropriate ioctl for device" In my rc.conf I had this statement vidcontrol -c blink -h 250 From testing it seems that vt does not handle the "blink" option for causing the cursor to blink. Is there a vt option to enable cursor blinking I've submitted two PRs for the issues you reported here: Bug 210413 - vidcontrol -c does not work with vt(4) Bug 210415 - vidcontrol -h does not work with vt(4) (edit) There is currently no option to enable cursor blinking. Further testing shows that: 1. The rc.conf option screen saver "saver= " and the "blanktime= " options work in vt for both text and graph modes. 2. The cursor copy/paste does not work in vt text mode. It only works in vt graph mode. vt needs to be fixed so copy/paste function also works in text mode. 3. Boot time splash screen does not work in vt at all no matter which mode is enabled. Using this in loader.conf splash_bmp_load="YES" bitmap_name="/boot/splash.bmp" bitload_load="YES" This works in 10.x. The splash screen function can not be allowed to be removed from the base system just because vt can not handle it. This also means any vt changes need to updated in the handbook section on splash screen. In conclusion, vt is not ready to replace the sc console driver yet. vt needs to be fixed before becoming the default in 11.0. Using vt as the default console driver effects every user. It completely changes the FreeBSD experience. It's detrimental to the public relations and the professional image of FreeBSD to publish the 11.0-RELEASE using vt in its current condition. If time doesn't permit to get these vt things fixed before publishing 11.0 then vt should not become the default console driver. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
John Baldwin wrote: On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote: Ed Maste wrote: On 20 June 2016 at 14:29, Ernie Luzar wrote: I found the cause of this boot time message "vicontrol: setting cursor type: Inappropriate ioctl for device" In my rc.conf I had this statement vidcontrol -c blink -h 250 From testing it seems that vt does not handle the "blink" option for causing the cursor to blink. Is there a vt option to enable cursor blinking I've submitted two PRs for the issues you reported here: Bug 210413 - vidcontrol -c does not work with vt(4) Bug 210415 - vidcontrol -h does not work with vt(4) (edit) There is currently no option to enable cursor blinking. Further testing shows that: 1. The rc.conf option screen saver "saver= " and the "blanktime= " options work in vt for both text and graph modes. 2. The cursor copy/paste does not work in vt text mode. It only works in vt graph mode. vt needs to be fixed so copy/paste function also works in text mode. 3. Boot time splash screen does not work in vt at all no matter which mode is enabled. Using this in loader.conf splash_bmp_load="YES" bitmap_name="/boot/splash.bmp" bitload_load="YES" This works in 10.x. The splash screen function can not be allowed to be removed from the base system just because vt can not handle it. This also means any vt changes need to updated in the handbook section on splash screen. In conclusion, vt is not ready to replace the sc console driver yet. vt needs to be fixed before becoming the default in 11.0. Using vt as the default console driver effects every user. It completely changes the FreeBSD experience. It's detrimental to the public relations and the professional image of FreeBSD to publish the 11.0-RELEASE using vt in its current condition. If time doesn't permit to get these vt things fixed before publishing 11.0 then vt should not become the default console driver. OTOH, if you use EFI, then you can't use sc(4). You get no working console with EFI (which is becoming more popular) if you use sc(4). You also do not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable console if you use sc(4). You also do not have a working console after loading the KMS drivers (either by starting X or via explicit kldload) when using sc(4). This affects just about every modern Intel system using an Intel GPU (so more widespread than EFI even). There are trade offs in both directions. Neither console is a subset of the other. However, sc(4) is not really expendable to support the things it is missing. vt(4) is actively worked on, and patches for the features it lacks that you need are certainly welcomed. This sounds like a integration design error. From your description of the hardware that vt is designed for and sc is designed for indicates the need for some code to be added to the boot process that inspects the hardware and decides whether vt or sc is to be launched. Or maybe bsdinstall should inspect the hardware and give the installer the option to select what console is best for his hardware. Just forcing this version of vt that lacks long time functions as the default console driver is not the professional way to handle such conflicts. I am at a lost to understand how any development administrator would approve making vt the default console driver in light of the standard functions missing from it. And furthermore what kind of vt testing was done that these problems were missed. Any one of these problems is enough cause to reverse the decision to make vt the default console driver for 11.0. This would give time for these problems to be address and correctly tested and when ready then be paced in some other 11.x release. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
Kurt Jaeger wrote: Hi! If you want textmode like in the old days, add this line to /boot/loader.conf: hw.vga.textmode="1" If I do this on a laptop 10.3p5, sending the laptop to sleep with zzz causes a crash (!), which is reproducable. submit a PR ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
Glen Barber wrote: On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote: On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: Hi, Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on Windows 10. It complained that the ISO is too big for my 700 MB CD-r. The bootonly iso (281MB) burns and runs ok. Regards, Ronald. Please open a PR. Those images should be able to fit on a CD. This was actually a known "going to be problem" thing for 11.0. I'm looking into how to fix this for 11.0-RELEASE, but right now, there is not much more we can exclude from it. :( Glen I burned 11.0-ALPHA6 to a 700 MB CD-r using "cdrecord -sao -overburn -disc1.iso" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Destroy GPT partition scheme absolutely, how?
Hartmann, O. wrote:
I ran into a very nasty and time consuming problem. Creating a NanoBSD
image with a modified script framework creating GPT partitions, I put
the imaes via "dd(1)" on USB flash or SD flash. Because the images are
usually much smaller than the overall capacity of the USB or SD, the OS
(FreeBSD CURRENT, recently built as of this morning) complains about
the second GPT header isn't in the last LBA. Sometimes, my PCengines
APU2 doesn't boot then, a relief is to issue the command
gpart recover da1
(in that case, the USB flash drive or SD flash is recognized
as /dev/da1).
But I run into a nasty situation, if the image put to the flash is
somehow corrupted. Then I tried to write a second, repaired image over
the first one using dd(1) again and do a recovering as mentioned above
- but this is fatal in two ways. First, the corrupted/broken GPT seems
to be "recovered" and put in replacement of the correct one - so I
guess. Performing no recover leaves the image on flash corrupted
anyway.
Well, to be honest, I didn't exactly know what is going on here. The
phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
partition with an empty NANO_DATASIZE which somehow corrupted the
whole image. The image then never booted, complaining,
that /foo/bar/_.mnt was unmounted unleanly.
This happened multiple times, even if I tried to overwrite the SD or
USB flash with /dev/zero or /dev/random data, but I do stop such a dd
after a couple f minutes, since the SD is 32GB in size and the USB
flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
to write via USB 2.0. But even with overwriting with a good image then
results in a corrupt image on flash drive, complaining about the GPT
second header not in last LBA and the issue with the uncleanly
unmount _.mnt (from the creation process of the NanoBSD image)!
So I guess there is something magic happening. Some informations are
not lost and I suspect the "recovery" moving those foul data into
active places.
Using a fresh/new SD or USB resolves the problem. But the question
remains: how can I destroy any relevant GPT information on a Flash
drive (or even harddisk) to avoid unwanted remains of an foul image
installation?
First guess was to write the last couple of bytes on such a flash drive
by letting dd(1) counting backwards, but I couldn't figure out how to
let dd(1) do such a procedure. The nightmare didn't end, while trying,
the SD flash card died :-(
thank you very much for your help and thoughts.
Kind regards, thanks in advance,
This little script has been posted before. Maybe it will be what your
looking for. Called gpart.nuke
#! /bin/sh
echo "What disk do you want"
echo "to wipe? For example - da1 :"
read disk
echo "OK, in 10 seconds I will destroy all data on $disk!"
echo "Press CTRL+C to abort!"
sleep 10
diskinfo ${disk} | while read disk sectorsize size sectors other
do
# Delete MBR and partition table.
dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
# Delete GEOM metadata.
dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors
- 2` count=2
done
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: jails in CURRENT: can not reach hosts on same network
O. Hartmann wrote: Hello list. I struggle with setting up jails on most recent CURRENT. The machine containing the jails has two NICs (bce0 and bce1). the host itself is supposed to own NIC bce0 exclusively - means, the services running on that NIC - syslogd, named and others - are bound to that NIC and should not be shared with the bce1 or jails bound to bce1. I followed the instructions given in the most recent version of the handbook setting up a jail. So far, so good. The NIC bce1 (the second one) is "aliased" with IPs from the local network. forwarding is disabled (net.inet.ip.forwarding: 0). Setup of each jail is straigh forward, with "ip4.addr=" set to the specific IP and interface="bce1". Within a jail, I can not reach an IP on the same network, not even the gateway by pinging or doing name resolutions using the DNS server on the local net! The curious thing is, by setting "nameserver 8.8.8.8" in /etc/resolv.conf, I can ping "outer world systems" and performing name resolutions as well - this implies, that the IP pakets are delegated to the local gateway and then further to the DNS of Google's. But pinging the local gateway directly (192.168.0.1) seems to be prohibited as well as pinging or reching any other IP on the net, including the bce0 of the same host (via default gateway?) or any other aliased IP. Since I'm new to jails and the complicated handling with networks, I miss something here which is probably not well documented. I found some notes on the forum about setfib, FIB, but I lack in the correct manpage to read more about this concept, the meaning for a jail and its probable impact in my situation. Following the suggestion setting net.add_addr_allfibs=0 in /boot/loader.conf seems to be senseless - after a reboot this OID is always set back to 1 (net.add_addr_allfibs=1). maybe someone has an idea what's wrong in principle with my attempts. thanks in advance for your patience, Oliver First of all trying to teach your self about LAN & jail usage using [CURRENT] is the wrong version of FreeBSD to be using because it's the bleeding edge where all the OS updates are tested. You should be using 10.3 or soon to be published 11.0. With CURRENT you can't tell if problems are caused by you not configuring something correctly or you fell into a OS bug. Now if you have a LAN & jail setup working on a RELEASE version and you really think your problem is caused by a bug in CURRENT then you need to come out and state that. But based on the tone of your post that is not the case. Secondly, the "current" list is the incorrect list to be posting this type of question. You should post this to the "questions" or the "jail" list. The ping command from within a jail is a considered a security risk and disabled by jail(8) design. It seems to me that you are mixing 2 separate problems, LAN configuration and jail configuration. You need to first get your LAN nodes talking to each other and with the host, before you add jail(8) into the mix. The standard LAN configuration runs a DHCP server on the host to assign private IP address to the LAN PC's when they power on. Since your host box functions as a [gateway box] with a LAN behind it you need to have gateway_enable="YES" in your hosts rc.conf file. You also need a firewall to NAT the private LAN IP addresses to the hosts public ISP issued IP address. I recommend ipfilter which is in the base system, it's open source and runs on most all other Unix flavored OS's making it very easy to use the same firewall rule set across other OS's. After you have your LAN nodes being able to ping the host and other nodes on the LAN, and also access the pubic internet, Then is the time to play with jails. I recommend you use the jail utility sysutil/qjail port. It simplifies jail management and is very user friendly. Be sure not to assign private IP addresses to jails that are controlled by DHCP or the LAN node will stop working when the jail starts using the same IP address. A detailed description of how you intend to us jails would go a long way to customizing any additional help you may require from posts to the "questions" list. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vt(4) chops off the leftmost three columns
Alan Somers wrote: I've seen three separate machines where FreeBSD11's vt(4) driver chops off the leftmost three columns of the screen. Rendering simply starts at the beginning of the fourth column. In all cases, setting "kern.vty=sc" corrects the problem. The three different systems are: 1) Haswell CPU with SuperMicro X10DRH-IT motherboard 2) Gainestown CPU with Dell S99 motherboard 3) Via Nano X2 CPU with VIA EPIA-M900 motherboard I don't have time to hack on vt myself as long as sc works fine. But if there's any way that I can help a vt developer, I'd be happy to do it. -Alan VT(4) already has open problems that no one is working on so may as well add this as another pr. VT should have had better testing before becoming the default in 11.0. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vt(4) chops off the leftmost three columns
You can add these things to the vt to-do list Change the default font to look like sc. Add copy/paste function like sc has. Add splash screen support like sc has. Adrian Chadd wrote: hi, no, the vt_vga backend doesn't yet do VESA. I keep meaning to sit down and fix this, but life and wifi gets in the way. -adrian On 14 January 2017 at 16:27, Kevin Oberman wrote: On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd wrote: It depends(tm). I think the VT code just does "640x480x4bpp" and lets the BIOS sort it out. A lot of things don't cope well with 640x480 these days - they try autodetecting picture edges, but a black border makes that very difficult. -adrian Can you use vidcontrol(1) to change to something better? 1600x900, maybe? (Note, I have not tried this and I know that vt does not support a lot of vidcontrol functionality, but starting X sets the display to 200x56 characters on my laptop.) -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On 14 January 2017 at 08:57, Matthias Andree wrote: Am 14.01.2017 um 00:11 schrieb Alan Somers: I take it back. The first three columns _are_ rendered, but they don't show up on some monitiors. It's as if those monitors require a minimum amount of overscan on the left side of the screen, and vt(4) doesn't provide enough. Can that be tuned? Once upon a time, I've seen similar things on Linux, but with fewer pixels offset, when switching framebuffer drivers - back then, the scanning-VGA-timing was an issue. Is there any way to tweak the row and column timings, with blank periods, viewport offsets and thereabouts? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
vt(4) bugs needing attention
Is anyone working the these outstanding vt(4) bug reports? Bug 210431 - vt(4) copy/paste mode does not work in hw.vga.textmode=1 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210431 Bug 210432 - vt(4) does not support boot time splash screen https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210432 Bug 210446 - vt(4) when switching between virtual consoles there is a 4 second hesitation in graph mode. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210446 Are fixes for these going to be in 11.1 release? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Is ipfilter firewall with ippool working?
I have been a ipfilter user since Freebsd 3.0 without any complaints. Now I'm trying to get ippool to function. I have been able to add a pool, but now I want to refresh it's contents. From what I read in "man 8 ippool", I have to remove the pool from core and then re-add it with the complete new content. When I issue this command to remove the named ippool from core, I get message saying "Segmentation fault (core dumped)" and the system continues as normal. ippool -R -m unsolicited I know that in 2016 ipfilter was forked and updated to be freebsd friendly. Thinking maybe something in the kernel code was changed that now is causing this problem. I'm running release 11.0. Is there anyone out there who has ipfilter/ippool working? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is ipfilter firewall with ippool working?
Cy Schubert wrote: In message <58e50379.6090...@gmail.com>, Ernie Luzar writes: I have been a ipfilter user since Freebsd 3.0 without any complaints. Now I'm trying to get ippool to function. I have been able to add a pool, but now I want to refresh it's contents. From what I read in "man 8 ippool", I have to remove the pool from core and then re-add it with the complete new content. When I issue this command to remove the named ippool from core, I get message saying "Segmentation fault (core dumped)" and the system continues as normal. ippool -R -m unsolicited I know that in 2016 ipfilter was forked and updated to be freebsd friendly. Thinking maybe something in the kernel code was changed that now is causing this problem. I'm running release 11.0. Is there anyone out there who has ipfilter/ippool working? Hi, I use ipfilter (and have for a couple of decades on Solaris and FreeBSD). We haven't forked it but we are fixing bugs and pushing them upstream. Looking at the ippool source, this is another case of the source or man page being incorrect. Looking at earlier versions of the source and man pages, it appears to have been broken for almost forever. This is not the first command line parsing issue or man page discrepancy in ipfilter. Can you please file a PR and assign it to me? The todos will be to: 1. Determine whether the man page or the code is correct. 2. Verify that all arguments are parsed (and subsequently processes). 3. Verify that correct error messages are produced as appropriate. For now you can issue ippool -R -m unsolicited POOL_TYPE, where pool type is documented in the man page with -t (though that will also need to be verified). The ippool parser thinks the pool type is a positional argument not an option. I'd like to verify Darren Reed's (original author's) intention before blindly "fixing" anything. Thank you for taking on this project to fix ippool. I have stumbled across many items that don't work as documented or the documentation doesn't provide enough information about the required syntax. Yes I can submit a pr. I will add to your to-do list pointing out things that need addressing. I have already tried "ippool -R -m unsolicited -t tree" and it gives error ilegal option --t The usage of this command is to remove the named pool from running in core so it can be re-added in mass with updated content. I can all most do the same thing using this command sequence ippool -f /etc/ippool.conf -u this unloads all the entries but leaves the pool name in place then this command reloads in mass ippool -f /etc/ippool.conf Can you suggest some other way the get ippool -R command working? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VNET branch destiny
peter.b...@bsd4all.org wrote: There have been issues with pf if I recall correctly. I currently have issues with stable, pf and vnet. There is an issue with pf table entries when an interface is moved to a different vnet. Does anyone no if there is a specific fix for this that hasn’t been ported to stable? I haven’t had the time to test this on current. Peter PF was fixed in 11.0 to not panic when run on a host that has vimage compiled into the kernel. On 11.0 you can configure pf to run in a vnet jail but it really does not enforce any firewall rules because pf needs access to the kernel which jail(8) is blocking by design. As far as I know this is a show shopper that can not be fixed without a pf rewrite changing the way it works internally. This PR gives all the details https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VNET branch destiny
To the VNET (VIMAGE) update project team members Release 11.0 has some out standing VNET (VIMAGE) PR's that need addressing. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212031 I believe 212000 and 212013 would require an rewrite replacing the kernel method they use to the user land method as used by ipfw. At the very lease it should be documented somewhere that pf & ipfilter do not work in an vnet/vimage jail. PR 212031 looks like a vimage/vnet problem to me. To the members of current, This bug report is not a jail(8) problem but a kernel problem that needs to be addressed. Could someone please look into fixing it. I effects all jail(8) users. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210049 There is also the matter of removing the depreciated rc.conf jail definition method from the rc.d scripts making the jail.conf method the default. This is long over due and maybe something over looked in the 11.0 release. Thank you for your attention. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VNET branch destiny
peter.b...@bsd4all.org wrote:
Well, in my case it panic’ed on 11-stable. I’m only using pf on the
host, not in the jail. I’m using Devin Teske’s jng to create a netgraph
bridge. It is my intention to use the netgrpah bridge with bhyve as well.
The panic (one-time) happened in pfioctl when I refreshed the rules. I
suspect the problem is related to the following message when I stop the
jail.
kernel: Freed UMA keg (pf table entries) was not empty (32 items). Lost
-57 pages of memory.
Current does not display the UMA message. I’m still narrowing down what
happens with the pf table entries. My suspicion is that the netgraph
bridge which creates a ng_ether device which is handed over to the
jail vnet, is causing this.
The panic happened on LIST_REMOVE in keg_fetch_slab
static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
uma_slab_t slab;
int reserve;
mtx_assert(&keg->uk_lock, MA_OWNED);
slab = NULL;
reserve = 0;
if ((flags & M_USE_RESERVE) == 0)
reserve = keg->uk_reserve;
for (;;) {
/*
* Find a slab with some space. Prefer slabs that are
partially
* used over those that are totally full. This helps to
reduce
* fragmentation.
*/
if (keg->uk_free > reserve) {
if (!LIST_EMPTY(&keg->uk_part_slab)) {
slab = LIST_FIRST(&keg->uk_part_slab);
} else {
slab = LIST_FIRST(&keg->uk_free_slab);
*LIST_REMOVE(slab, us_link);*
LIST_INSERT_HEAD(&keg->uk_part_slab, slab,
us_link);
}
MPASS(slab->us_keg == keg);
return (slab);
}
KDB: stack backtrace:
#0 0x805df0e7 at kdb_backtrace+0x67
#1 0x8059d176 at vpanic+0x186
#2 0x8059cfe3 at panic+0x43
#3 0x808ebaa2 at trap_fatal+0x322
#4 0x808ebaf9 at trap_pfault+0x49
#5 0x808eb336 at trap+0x286
#6 0x808d1441 at calltrap+0x8
#7 0x808a871e at zone_fetch_slab+0x6e
#8 0x808a87cd at zone_import+0x4d
#9 0x808a4fc9 at uma_zalloc_arg+0x529
#10 0x80803214 at pfr_ina_define+0x584
#11 0x807f0734 at pfioctl+0x3364
#12 0x80469288 at devfs_ioctl_f+0x128
#13 0x805fa925 at kern_ioctl+0x255
#14 0x805fa65f at sys_ioctl+0x16f
#15 0x808ec604 at amd64_syscall+0x6c4
#16 0x808d172b at Xfast_syscall+0xfb
The panic is so far not reproducible.
On 10 Apr 2017, at 15:50, Ernie Luzar <mailto:luzar...@gmail.com>> wrote:
peter.b...@bsd4all.org <mailto:peter.b...@bsd4all.org> wrote:
There have been issues with pf if I recall correctly. I currently
have issues with stable, pf and vnet. There is an issue with pf table
entries when an interface is moved to a different vnet.
Does anyone no if there is a specific fix for this that hasn’t been
ported to stable? I haven’t had the time to test this on current.
Peter
PF was fixed in 11.0 to not panic when run on a host that has vimage
compiled into the kernel. On 11.0 you can configure pf to run in a
vnet jail but it really does not enforce any firewall rules because pf
needs access to the kernel which jail(8) is blocking by design. As far
as I know this is a show shopper that can not be fixed without a pf
rewrite changing the way it works internally.
This PR gives all the details
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
I also tested using Devin Teske’s jng to create a netgraph bridge on
RELEASE 10.0 and it worked. But when I tried the same configuration on
RELEASE 11.0 it no longer worked.
I strongly suggest you verify pf is functional in your vnet jail before
you go chasing a dump which I suspect is totally misleading.
Setup a simple vnet pf rule set being run in the vnet jail that allows
everything out except port 43 which the "whois" command uses and then
issue the whois command from the vent jail console. If the vnet pf port
43 rule is really blocking port 43 it will cause the whois command to
not return any results. If the whois command returns results this
indicates that even thought you have all the correct settings to run pf
in your vnet jail and have received no error messages about it, pf is
not really enforcing any rules. (IE; not working) I am assuming that
the host has no firewall at all or is at least allowing outbound port 43
packets out.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VNET branch destiny
peter.b...@bsd4all.org wrote: Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, not in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It is my intention to use the netgrpah bridge with bhyve as well. I also tested using Devin Teske’s jng to create a netgraph bridge on RELEASE 10.0 and it worked. But when I tried the same configuration on RELEASE 11.0 it no longer worked. Sorry for the noise. I missed this sentence. "I’m only using pf on the host, not in the jail.". Thats what happens when I answer email after a long day at work. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
csh script help
To aid in debugging the script I'm writing, I place "echo" commands throughout so I can kind of have a trace of the logic as different conditions are processed. Normally I just delete these "echo" commands after I get the script working. But this time I want to try something different. I want to enable/disable the echo commands in mass. So in the beginning of the script I added these 2 lints. #trace="" # use to enable trace echo trace="#" # use to disable trace echo In front of each of the echo commands I added this, $trace echo "what ever." When I exec the script I get error message #: not found What is happing here? Is the substitution to late? Is there a way to fix this? Thanks for your help ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: csh script help
Chuck Swiger wrote: On Apr 14, 2017, at 6:47 AM, Ernie Luzar wrote: To aid in debugging the script I'm writing, I place "echo" commands throughout so I can kind of have a trace of the logic as different conditions are processed. Normally I just delete these "echo" commands after I get the script working. Since you've gotten an answer to the question you asked, let me only note that both sh and csh support the -x flag, which causes the shell to echo the commands as it runs. This is extremely helpful for debugging. Regards, Where is the this -x flag coded at? Do the executed lines roll fast off the screen or can I slowly step through the script a line at a time? Thanks for this bit of information. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
watchdog timeout problem
Posted this 10/31/2017 got no reply. Been getting these error messages since about release 10.0 I think. Have changed to new hardware box and new cable modem and still having the same error messages. Also occurs when I use em0 interface to connect to the public internet instead of vge0. vge0: flags=8843 metric 0 mtu 1500 options=389b ether 00:0b:db:19:33:18 hwaddr 10:00:60:21:00:93 inet xxx.xxx.xxx.xxx netmask 0xf000 broadcast 255.255.255.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active Oct 30 23:43:38 fbsd kernel: vge0: watchdog timeout Oct 30 23:43:38 fbsd kernel: vge0: link state changed to DOWN Oct 30 23:43:42 fbsd kernel: vge0: link state changed to UP Oct 30 23:58:39 fbsd kernel: vge0: watchdog timeout Oct 30 23:58:39 fbsd kernel: vge0: link state changed to DOWN Oct 30 23:58:43 fbsd kernel: vge0: link state changed to UP Oct 31 01:08:38 fbsd kernel: vge0: watchdog timeout Oct 31 01:08:38 fbsd kernel: vge0: link state changed to DOWN Oct 31 01:08:42 fbsd kernel: vge0: link state changed to UP Oct 31 01:53:39 fbsd kernel: vge0: watchdog timeout Oct 31 01:53:39 fbsd kernel: vge0: link state changed to DOWN Oct 31 01:53:43 fbsd kernel: vge0: link state changed to UPdob Oct 31 04:58:46 fbsd kernel: vge0: watchdog timeout Oct 31 04:58:46 fbsd kernel: vge0: link state changed to DOWN Oct 31 04:58:50 fbsd kernel: vge0: link state changed to UP Oct 31 05:23:49 fbsd kernel: vge0: watchdog timeout Oct 31 05:23:49 fbsd kernel: vge0: link state changed to DOWN Oct 31 05:23:52 fbsd kernel: vge0: link state changed to UP Oct 31 05:57:40 fbsd kernel: vge0: watchdog timeout Oct 31 05:57:40 fbsd kernel: vge0: link state changed to DOWN Oct 31 05:57:43 fbsd kernel: vge0: link state changed to UP Oct 31 09:21:43 fbsd kernel: vge0: watchdog timeout Oct 31 09:21:43 fbsd kernel: vge0: link state changed to DOWN Oct 31 09:21:47 fbsd kernel: vge0: link state changed to UP Oct 31 09:28:21 fbsd kernel: vge0: watchdog timeout Oct 31 09:28:21 fbsd kernel: vge0: link state changed to DOWN Oct 31 09:28:25 fbsd kernel: vge0: link state changed to UP 11/2/2017 posting this now as a update I have continued to research this problem. The "man watchdog" says that the command, watchdog -d will provide debugging info, and watchdog -t will set a new timeout timer value When I issue either of those commands I get this error message watchdog: patting the dog: Operation not supported The man page also says a value of -t 0 disables the watchdog function. Issuing "watchdog -t 0" does not get that above error message, but the watchdog function is still enabled because I am still getting the kernel: vge0: watchdog timeout kernel: vge0: link state changed to DOWN kernel: vge0: link state changed to UP messages. Production box is running RELEASE AMD64 11.1 and has 16 MB memory, with 2 Gigabit interface cards em0 & vge0. Development box is running RELEASE i386 11.1 beta 1 and has 2 MB memory, with 2 100bps interface cards rl0 & xl0. The 2 boxes are desktops manufactured by 2 different name brand companies. Both computers run the same host services. Both computers experience the same watchdog problems. This watchdog problem is also present in RELEASE 11.0 and if my memory is correct also occurred in the 10.x series. I never paid attention to this problem until lately when I am now streaming HULU and the show stops because the internet connection is lost due to the link state being reset by watchdog. Now this problem is really a problem that is impacting me. Can't see how this could be a configuration problem on my part. That is why I am posting here before I post a bug report. Watchdog is in the kernel and debugging the kernel is way outside my abilities. Trying to get this problem in front of the correct audience. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: watchdog timeout problem
YongHyeon PYUN wrote: On Thu, Nov 02, 2017 at 10:13:15AM -0400, Ernie Luzar wrote: Posted this 10/31/2017 got no reply. Been getting these error messages since about release 10.0 I think. Have changed to new hardware box and new cable modem and still having the same error messages. Also occurs when I use em0 interface to connect to the public internet instead of vge0. vge0: flags=8843 metric 0 mtu 1500 options=389b ether 00:0b:db:19:33:18 hwaddr 10:00:60:21:00:93 inet xxx.xxx.xxx.xxx netmask 0xf000 broadcast 255.255.255.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active Oct 30 23:43:38 fbsd kernel: vge0: watchdog timeout Oct 30 23:43:38 fbsd kernel: vge0: link state changed to DOWN Oct 30 23:43:42 fbsd kernel: vge0: link state changed to UP 11/2/2017 posting this now as a update I have continued to research this problem. The "man watchdog" says that the command, watchdog -d will provide debugging info, and watchdog -t will set a new timeout timer value When I issue either of those commands I get this error message watchdog: patting the dog: Operation not supported The man page also says a value of -t 0 disables the watchdog function. Issuing "watchdog -t 0" does not get that above error message, but the watchdog function is still enabled because I am still getting the kernel: vge0: watchdog timeout kernel: vge0: link state changed to DOWN kernel: vge0: link state changed to UP messages. For the archives. After a lot of trial and error testing finally determined the cause of this problem is ddclient. When I disable ddclient from running those messages stop happening. ddclient is a dynamic DNS auto updater written in perl. I have now deinstalled ddclient and written my own dynamic DNS auto updater sh script that I am calling dynip with intention to add it to the port system later. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ipv6_ipfilter_rules= is obsolete ?
In /etc/defaults/rc.conf I see this ipv6_ipfilter_rules="/etc/ipf6.rules" # rules definition file for ipfilter, # see /usr/src/contrib/ipfilter/rules for examples man 8 ipf says ipf -6 ipv4 and ipv6 rules are stored in a single table and can be read from a single file. This option is no longer required to load ipv6 rules. I interrupt this to mean that the ipv6_ipfilter_rules="/etc/ipf6.rules" line in /etc/defaults/rc.conf is obsolete and should be removed before RELEASE 13.0 is published for users to use. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_ipfilter_rules= is obsolete ?
Gary Jennejohn wrote: On Thu, 9 Jul 2020 10:27:02 +0800 Marcelo Araujo wrote: Em qui., 9 de jul. de 2020 __s 07:34, Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> escreveu: In /etc/defaults/rc.conf I see this ipv6_ipfilter_rules="/etc/ipf6.rules" # rules definition file for ipfilter, # see /usr/src/contrib/ipfilter/rules for examples man 8 ipf says ipf -6 ipv4 and ipv6 rules are stored in a single table and can be read from a single file. This option is no longer required to load ipv6 rules. I interrupt this to mean that the ipv6_ipfilter_rules="/etc/ipf6.rules" line in /etc/defaults/rc.conf is obsolete and should be removed before RELEASE 13.0 is published for users to use. Interesting, though I would not remove it. It should be marked as depricated and the /etc/rc.d/ipfilter shell script updated to emit a warning that it is depricated, but it should still be processed to retain backwards compatibility and NOT lock someone out of a system who has just done an upgrade to a newer version. Do you mean deprecated or depricated? Got confused here! Sorry English is hard for non-native speakers. It's a typo - he meant deprecated. This "retain backwards compatibility stuff" can be taken too far backwards. I think ipfilter first can out with NO ipv6 support, then ipv6 was added using 2 rule files, and later yet it was redesigned to use a single rules file. Talking about way back around RELEASE 4.0. Now ipfilter does not work with 2 rules files for a very long time. It's now time to clean up the old ipv6 only stuff so the documentation and /etc/rc.d/ipfilter boot script reflects how it works today. And another thing to point out is the ipfilter source code has been forked and is now under Freebsd maintainership. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_ipfilter_rules= is obsolete ?
Gary Jennejohn wrote: On Thu, 9 Jul 2020 10:27:02 +0800 Marcelo Araujo wrote: Em qui., 9 de jul. de 2020 __s 07:34, Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> escreveu: In /etc/defaults/rc.conf I see this ipv6_ipfilter_rules="/etc/ipf6.rules" # rules definition file for ipfilter, # see /usr/src/contrib/ipfilter/rules for examples man 8 ipf says ipf -6 ipv4 and ipv6 rules are stored in a single table and can be read from a single file. This option is no longer required to load ipv6 rules. I interrupt this to mean that the ipv6_ipfilter_rules="/etc/ipf6.rules" line in /etc/defaults/rc.conf is obsolete and should be removed before RELEASE 13.0 is published for users to use. Interesting, though I would not remove it. It should be marked as depricated and the /etc/rc.d/ipfilter shell script updated to emit a warning that it is depricated, but it should still be processed to retain backwards compatibility and NOT lock someone out of a system who has just done an upgrade to a newer version. Do you mean deprecated or depricated? Got confused here! Sorry English is hard for non-native speakers. It's a typo - he meant deprecated. This "retain backwards compatibility stuff" can be taken too far backwards. I think ipfilter first can out with NO ipv6 support, then ipv6 was added using 2 rule files, and later yet it was redesigned to use a single rules file. Talking about way back around RELEASE 4.0. Now ipfilter does not work with 2 rules files for a very long time. It's now time to clean up the old ipv6 only stuff so the documentation and /etc/rc.d/ipfilter boot script reflects how it works today. And another thing to point out is the ipfilter source code has been forked and is now under Freebsd maintainership. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
is updated if_bridge included in current 13.0 or stable 12
Know if_bridge is being worked on to make its performance faster. Has this new if_bridge been merged into 13.0 current head or stable 12.2? If so I would like to give it a test ride by installing last weeks snapshot. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vnet/jail crashdump
Ronald Klop wrote:
Hi,
After stopping a jail I get a crashdump.
core.txt:
https://www.klop.ws/core_2eef39c581f90f2f0c4921e43f1998c1/core.txt.0
Jail.conf:
--
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.clean;
exec.prestart = "ifconfig bridge0 > /dev/null 2> /dev/null || ( ifconfig
bridge0 create && ifconfig bridge0 addm vtnet0 && ifconfig bridge0 up)";
exec.consolelog = "/var/log/jail_${name}_console.log";
mount.devfs;
path = "/data/jails/$name";
host.hostname = "$name";
mount.fstab = "/data/jails/fstab.$name";
vnet;
allow.mlock;
devfs_ruleset="110";
freebsd12 {
osrelease = 12.1-RELEASE-p4;
osreldate = 1201000;
vnet.interface = "epair0b";
# make sure the exec.prestart has a "+=" as we de it in the global
definition
# when checking for the bridge
exec.prestart += "ifconfig epair0 create up";
exec.prestart += "ifconfig bridge0 addm epair0a";
exec.prestart += "ifconfig epair0b link 02:xx:0c";
exec.start = "dhclient epair0b";
exec.start += "/bin/sh /etc/rc";
exec.poststop = "ifconfig bridge0 deletem epair0a";
exec.poststop += "ifconfig epair0a destroy";
}
freebsd13 {
vnet.interface = "epair1b";
# make sure the exec.prestart has a "+=" as we de it in the global
definition
# when checking for the bridge
exec.prestart += "ifconfig epair1 create up";
exec.prestart += "ifconfig bridge0 addm epair1a";
exec.prestart += "ifconfig epair1b link 02:xx:0d";
exec.start = "dhclient epair1b";
exec.start += "/bin/sh /etc/rc";
exec.poststop = "ifconfig bridge0 deletem epair1a";
exec.poststop += "ifconfig epair1a destroy";
}
--
What can I do to help debug?
Don't understand why you have these 2 statements
exec.prestart += "ifconfig epair1b link 02:xx:0d";
exec.start = "dhclient epair1b";
There is a well known bug with bridge vnet tear down since release 9.0.
Their is a rewrite of if_bridge going on right now to fix the problem
and increase the performance of if_bridge. As of today this fix is not
in 12.2 stable or 13.0 current.
There also looks like a bug in jail(8) when you have both vnet jails and
non-vnet jails being started on the same host at the same time. In most
cases the host just loses internet access until all the jails are
stopped. Some times you will get a system crash.
This jail.conf def seems to work around the bridge tear down problem
# vnet jail using the bridge/epair method on 12.1
v0jail1 {
host.hostname = "v0jail1";
path= "/usr/jails/v0jail1";
mount.fstab = "/usr/local/etc/fstab/v0jail1";
exec.consolelog = "/var/log/v0jail1.console.log";
mount.devfs;
devfs_ruleset = "4";
vnet= "new";
vnet.interface = "epair55b";
exec.prestart = "ifconfig epair55 create up";
exec.prestart += "ifconfig bridge0 addm epair55a";
exec.prestart += "ifconfig epair55a descr vnet-v0jail1";
exec.prestart += "ifconfig bridge0 inet 10.0.48.2 netmask 255.255.255.0
alias";
exec.start = "/bin/sh /etc/rc";
exec.start += "ifconfig epair55b inet 10.0.48.1 netmask 255.255.255.0";
exec.start += "route add default 10.0.48.2";
exec.prestop= "ifconfig epair55b -vnet v0jail1";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.poststop = "ifconfig bridge0 deletem epair55a";
exec.poststop += "sleep 2";
exec.poststop += "ifconfig epair55a destroy";
exec.poststop += "ifconfig bridge0 inet 10.0.48.2 -alias";
}
Remember that your host firewall processes all traffic in & out of the
host including any vnet jail traffic. Yes a vnet jail has its own stack
and can have its own firewall, but the host firewall still has the last
say. The host must NAT any private ip addresses used by the vnet jails.
jail.conf jail definitions are based on hard codded ip addresses. You
can not use the host dhcp to assign local lan private ip addresses to a
jail.
You may find this helpful
https://forums.freebsd.org/threads/vnet-jail-with-public-internet-access-using-the-bridge-epair-method.76071/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: jail fib no longer works after net.add_addr_allfibs=0
I think you are all barking up the wrong tree The default OS comes with only ONE fib. You need to re-compile the kernel with "option ROUTETABLES=2" or use the net.fibs=2 option in /boot/loader.config file. 0= default host routing table 1= first additional routing table 2= second additional routing table Then issue host console commend; setfib 1 route add default "that jails default route ip address" Adding the above to /etc/rc.conf would make it happen on every boot of the host system. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
remove deprecated /etc/rc.d/jail script support for old rc.conf jail definitions from 13.0
The /etc/rc.d/jail script contains the on-the-fly conversion from the legacy rc.conf method statements to jail.conf file formate. The jail.conf was added in freebsd 9.0 and its now time to remove the deprecated support for the old definition method. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
