If we can ensure that the key is stored somewhere halfway secure (Jenkins Keystore) it would be okay.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 22 2018
Oct 21 2018
Problem is partly fixed in the latest rolling release. Only this manual step is required in addition at this time:
Oct 20 2018
Ah, yeah! Used that in my current project.
What's required for Kernel Debug?
Okay - I just see that the allow-root feature wasn't working anyway since the SSH XML rewrite.
Invalid: Modules like SIP conntrack can't be adjusted during runtime (at least I have not found a way). Only module load parameters are supported. :(
Both SNMP and TFTP now print a warning. In a subsequent step we could change this to be an error on commit and introduce a migration script deleting invalid addresses to not kill currently deployed configs!
I will implement at least a warning message for the user. Enforcing proper IP addresses could break old comfigurations - or they should be deleted by a migration script and then we can print proper error messages.
oth deletion and alias is ok for me. @syncer?
Remove or not remove?
Installing a debug image requires a reboot. apt-get installation works online.
Why? Someone can always install any 3rd party debian package via apt after setting up the repositories. This is in no way different to a parallel build and super easy.
Thats already possible using the custom package option introduced by @dmbaturin
Oct 19 2018
Oct 17 2018
Oct 16 2018
Oct 15 2018
Not at this time.
@Merijn this look slike a problem with a validation script in VyOS - sorry.
ipaddrcheck_functions.c ipaddrcheck_functions.c: In function ‘is_ipv6_cidr’: ipaddrcheck_functions.c:104:23: error: unknown escape sequence: '\.' [-Werror] re = pcre_compile("^(((?:(?:(?:[A-F0-9]{1,4}:){6}|(?=(?:[A-F0-9]{0,4}:){0,6}(?:[0-9]{1,3}\.){3}[0-9]{1,3}$)(([0-9A-F]{1,4}:){0,5}|:)((:[0-9A-F]{1,4}){1,5}:|:)|::(?:[A-F0-9]{1,4}:){5})(?:(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])|(?:[A-F0-9]{1,4}:){7}[A-F0-9]{1,4}|(?=(?:[A-F0-9]{0,4}:){0,7}[A-F0-9]{0,4}$)(([0-9A-F]{1,4}:){1,7}|:)((:[0-9A-F]{1,4}){1,7}|:)|(?:[A-F0-9]{1,4}:){7}:|:(:[A-F0-9]{1,4}){7}))(\\/\\d{1,3}))$", ^ ipaddrcheck_functions.c:104:23: error: unknown escape sequence: '\.' [-Werror] ipaddrcheck_functions.c: In function ‘is_ipv6_single’: ipaddrcheck_functions.c:131:23: error: unknown escape sequence: '\.' [-Werror] re = pcre_compile("^(?:(?:(?:[A-F0-9]{1,4}:){6}|(?=(?:[A-F0-9]{0,4}:){0,6}(?:[0-9]{1,3}\.){3}[0-9]{1,3}$)(([0-9A-F]{1,4}:){0,5}|:)((:[0-9A-F]{1,4}){1,5}:|:)|::(?:[A-F0-9]{1,4}:){5})(?:(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])|(?:[A-F0-9]{1,4}:){7}[A-F0-9]{1,4}|(?=(?:[A-F0-9]{0,4}:){0,7}[A-F0-9]{0,4}$)(([0-9A-F]{1,4}:){1,7}|:)((:[0-9A-F]{1,4}){1,7}|:)|(?:[A-F0-9]{1,4}:){7}:|:(:[A-F0-9]{1,4}){7})$", ^ ipaddrcheck_functions.c:131:23: error: unknown escape sequence: '\.' [-Werror] cc1: all warnings being treated as errors Makefile:363: recipe for target 'ipaddrcheck_functions.o' failed make[3]: *** [ipaddrcheck_functions.o] Error 1 make[3]: Leaving directory '/home/jenkins/workspace/ipaddrcheck/build/jessie64devel.vyos.net/src'
With less powerfull hardware (as this Atom D525) I'm fine with this change request.
Oct 14 2018
Problem still exists with 1.2.0-rolling+201810120820-amd64.iso
Can you provide your configuration, please?
Oct 11 2018
Okay, the problem is not DMVPN relevant. I have a weird OSPF routing problem. When disabling OSPF between both routers everything is ok.
Oct 10 2018
vyos-documentation is still a playground but feel free to add. Always makes sense to play arround with new concepts
According to http://conntrack-tools.netfilter.org/manual.html
Oct 9 2018
Ok, I can confirm that above config from @runar works for this setup using all VyOS 1.2.0-rc images
Okay, the above error
Killing OpenNHRP as suggested by @runar and relaunching it with:
Oct 8 2018
The problem still exists using VyOS 1.2.0-rc1.
Oct 7 2018
At time of this writing we don‘t support any GPU drivers in the 4.18 branch, obly framebuffer.
THX for testing. I'm currently buiulding a second image for testing and will keep you updated! The second one ships Linux Kernel 4.19-rc6 so we can see if the issue still exists or is gone!
Okay, can you please test if the issue exists with the following image:
Anyone also tried loading some up2date firmware from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ ?
We can switch back to 4.14. for testing, yes
Oct 3 2018
I think it's better to assign @dmbaturin b/c he build the used pdns package located at http://dev.packages.vyos.net/repositories/current/debian/pool/main/p/pdns-recursor/ and I have no access to this location.
Sure, what I need to do?
Oct 2 2018
Latest Firmware can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/
@deafen can you please retest with latest VyOS 1.2.0 rolling? We have the latest 4.18.11 Kernel now.
Sep 27 2018
This will be a killer feature. I wanted to spin a Atom C3000 board with VyOS 1.2 but that board comes with UEFI only so right now, no VyOS on this one. Debian Jessie CD on the other hand boots fine (build with UEFI support)
Sep 25 2018
VyOS 1.3 is fine for me
Sep 23 2018
What happens on Hypervisors not supporting UEFI or older Hardware Platforms without UEFI?
I think we should take care about this in the VRRP scripts and leave the base system untouched. Meaning, take your proposal and remove
update_sysctl_conf net.ipv4.conf.default.arp_filter 1 \ "reset promiscous arp response"
@rps seems to be the case. sorry for the noise
arp_proxy setting was introduced in an ancient commit https://github.com/vyos/vyatta-cfg-system/commit/496526b572ca83308a858b2ec4771d2f05f4970c
Sep 21 2018
@dmbaturin I actually comitted the fix yesterday morning. Somehow Phabricator only shows the corresponding commits when logged in.
Sep 20 2018
Sep 19 2018
Please find some older rolling releases here:
Sep 18 2018
As requested by @runar:
Sep 16 2018
Invalid SNMP addresses must be filtered, else the service won't start with this error message:
Sep 16 20:32:58 LR1 snmpd[4848]: Error opening specified endpoint "udp:192.168.1.1:161" Sep 16 20:32:58 LR1 snmpd[4848]: Server Exiting with code 1 Sep 16 20:32:58 LR1 snmpd[4845]: Starting SNMP services:: Sep 16 20:32:58 LR1 systemd[1]: snmpd.service: control process exited, code=exited status=1 Sep 16 20:32:58 LR1 systemd[1]: Failed to start LSB: SNMP agents. Sep 16 20:32:58 LR1 systemd[1]: Unit snmpd.service entered failed state.