Development October 2014

development@lists.ipfire.org

3 participants
6 discussions

Introducing DDNS
by Michael Tremer 21 Jun '16

21 Jun '16

Hello, this is a post to update you all about the recent developments regarding the support for the various upcoming dynamic DNS providers. Rationale Some of the major dynamic DNS providers stopped their free services or made them unusable so that people started searching for alternatives. In IPFire 2, a script called setddns.pl [1] is responsible for updating the dynamic DNS records. This script has grown over the last couple of months and if you have looked into it you will have noticed that it has become from ugly to almost un-maintainable. The decision that we don't want to take this mess with us into the next generation of IPFire was already made many years ago. DDNS A project called ddns was started which is a pure Python client that is much more flexible, cleanly rewritten and easily extensible. It is cross-platform, cross-distribution and does not need any third-party python modules. The basics already written years ago, Stefan Schantl and I worked on making this ready for IPFire 2 and added all the providers that are currently supported by setddns.pl and ez-ipupdate. The source for the new DDNS tool can be found over here: http://git.ipfire.org/?p=ddns.git;a=summary or on GitHub https://github.com/ipfire/ddns were you can send us pull requests for supporting new providers and so on. Bug reports go to the usual place: https://bugzilla.ipfire.org/describecomponents.cgi?product=DDNS%20Updater There is no fixed release schedule for this, but we are pretty sure that this won't take long until DDNS arrives in IPFire 2. That means that we won't take any patches for the setddns.pl script that add support for new providers any more. We appreciate any contribution and as always hope to get some feedback back from the community! Best, -Michael [1] http://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/scripts/setddns.pl;h=5…

6 18

IPFire2.x build hangs already on ICMPv6
by Sascha Kilian 10 Nov '14

10 Nov '14

Hi, after some time i was not here, i am back :) I build IPFire again from Scratch and it already hangs on Nagios 3.0.6 Log Snipp checking for ping... /bin/ping checking for ping6... no checking for ICMP ping syntax... /bin/ping -n -U -w %d -c %d %s checking for ICMPv6 ping syntax... I have sended a lfs patch for Nagios and other modules to remove IPV6 Support from IPFire 2.x to compile IPFire 2.x success. I rebuild my Patches and give u the github Repository from me :) If there a other Workaround for this bug? best regards Sascha

2 4

Bug Report - setup
by R. W. Rodolico 31 Oct '14

31 Oct '14

I was having some problems with a remote router not resolving addresses, so I started 'setup' from the CLI to change them. When I did this, I had the same problem (and suspected a network issue). Clearing dnsmasq (dnsmasqctl restart) showed it was still using the old DNS servers. The router is using DHCP for the red interface, but I am trying to override the DNS given by them (it is their little monitoring tool). Investigating, I found the following happened: 1. DNS settings appear in two places /var/ipfire/ethernet/settings /var/ipfire/dns/settings 2. 'setup' modifies /var/ipfire/ethernet/settings, but does not modify /var/ipfire/dns/settings. It appears dnsmasql uses /var/ipfire/dns/settings. 3. In the webui, 'Network | Assign DNS Server' reads /var/ipfire/dns/settings, so changes made there correctly work. Resolution: Either fix the code or simply remove the text that says you can change the DNS for DHCP there: Enter the DNS and gateway information. These settings are used only with Static IP (and DHCP if DNS set) on the RED interface. Frankly, the latter would be easiest, and most people will use the WebGUI, and weirdos like me will simply edit the settings file if I happen to need to change it from the CLI. Rod -- "Rod" Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net

2 5

Bug report - Snort
by R. W. Rodolico 28 Oct '14

28 Oct '14

Occurs in at least Core Update 84 and 85. When setting up Snort, and choosing 'Sourcefire VRT rules for registered users', the following error comes up. This is with a valid oinkcode which I've replaced below with xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.: ====================================================================== --2014-10-25 21:50:26-- http://www.snort.org/reg-rules/snortrules-snapshot-2960.tar.gz/xxxxxxxxxxxx… Resolving www.snort.org (www.snort.org)... 50.19.124.119, 54.225.152.149, 54.243.242.66 Connecting to www.snort.org (www.snort.org)|50.19.124.119|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.snort.org/reg-rules/snortrules-snapshot-2960.tar.gz/xxxxxxxxxxx… [following] --2014-10-25 21:50:26-- https://www.snort.org/reg-rules/snortrules-snapshot-2960.tar.gz/xxxxxxxxxxx… Connecting to www.snort.org (www.snort.org)|50.19.124.119|:443... connected. WARNING: cannot verify www.snort.org's certificate, issued by '/C=US/O=Thawte, Inc./CN=Thawte SSL CA': Self-signed certificate encountered. HTTP request sent, awaiting response... 422 Unprocessable Entity 2014-10-25 21:50:26 ERROR 422: Unprocessable Entity. ====================================================================== Visiting the URL's individually (with the oinkcode) results in the error message: ["File not found by name 'snortrules-snapshot-2960.tar.gz'"] These entries appear to be hard coded on line 265 of ids.cgi (/srv/web/ipfire/cgi-bin/ids.cgi) Updating with "Snort/VRT GPLv2 Community Rules" and "Emergingtrheats.net Community Rules" appear to work (I was not able to test the "Subscription" set since I do not have a subscription. Rod -- "Rod" Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net

2 1

RSA/SHA1-NSEC3-SHA1 signature bug?
by Michael Tremer 22 Oct '14

22 Oct '14

Hello fellow dnsmasq users, there is a topic on the IPFire support forums I would like to point you to: http://forum.ipfire.org/index.php?topic=11726.0 It appears that dnsmasq cannot verify resource records of a DNSSEC-enabled domain. That domain uses RSA/SHA1-NSEC3-SHA1 for its signatures. Although there is some code in dnsmasq that is supposed to handle this, it does not verify the records correctly. Did anyone else experience this problem? Is it a bug with dnsmasq or the authoritative name servers of that domain? Best, -Michael

2 3

Samba
by Michael Liekmeier 01 Oct '14

01 Oct '14

Hello, I use IPFire core 83 and can't install samba. It looks like that cups or krb5 makes the problem during the installing. Regards Michael

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development October 2014