Search results for "dnsmasq" - users

Re: freaking TFTP

by lejeczek

On 07/11/2023 15:42, Chris Adams wrote: > Once upon a time, lejeczek <peljasz(a)yahoo.co.uk> said: >> 2nd meanwhile - I'm trying _dnsmasq_ which I'm new to thus errors >> are possible but... it seems that the same issue remains. >> >> with _dnsmasq_. tftp client - as with in.tftp as the server - "times >> out" but _dnsmasq_ server thinks and says that: > I use dnsmasq's TFTP server on a bridge, with this config: > > bind-interfaces > interface=br0 > port=0 > enable-tftp > tftp-root=/srv/tftpboot > > "port=0" disables DNS, and I then don't configure DHCP, so it's just a > TFTP server. > I also should have added that it's Centos I'm doing all this on, with kernel from _elrepo_ Anybody here do/use Centos that way, with net bridges?

5 months, 1 week

Re: freaking TFTP

by lejeczek

On 07/11/2023 15:42, Chris Adams wrote: > Once upon a time, lejeczek <peljasz(a)yahoo.co.uk> said: >> 2nd meanwhile - I'm trying _dnsmasq_ which I'm new to thus errors >> are possible but... it seems that the same issue remains. >> >> with _dnsmasq_. tftp client - as with in.tftp as the server - "times >> out" but _dnsmasq_ server thinks and says that: > I use dnsmasq's TFTP server on a bridge, with this config: > > bind-interfaces > interface=br0 > port=0 > enable-tftp > tftp-root=/srv/tftpboot > > "port=0" disables DNS, and I then don't configure DHCP, so it's just a > TFTP server. > I started with that - got logs as shown in my last email. One thing I should perhaps mention, is that libvirt uses my NM bridges, but it's simple: -> $ virsh net-dumpxml 10_1_1 <network> <name>10_1_1</name> <uuid>864fb78e-0fb0-4c32-bb47-0e5ac68d9491</uuid> <forward mode='bridge'/> <bridge name='nm-bridge1011'/> </network> and I guess, but that does not "add" to on-bare-metal NM bridge.

5 months, 1 week

Re: freaking TFTP

by Chris Adams

Once upon a time, lejeczek <peljasz(a)yahoo.co.uk> said: > 2nd meanwhile - I'm trying _dnsmasq_ which I'm new to thus errors > are possible but... it seems that the same issue remains. > > with _dnsmasq_. tftp client - as with in.tftp as the server - "times > out" but _dnsmasq_ server thinks and says that: I use dnsmasq's TFTP server on a bridge, with this config: bind-interfaces interface=br0 port=0 enable-tftp tftp-root=/srv/tftpboot "port=0" disables DNS, and I then don't configure DHCP, so it's just a TFTP server. -- Chris Adams <linux(a)cmadams.net>

5 months, 1 week

Re: Anyone else seeing libvirtd refusing connections after a day?

by Robert McBroom

Putting VIRTNETWORKD_ARGS= in /etc/sysconfig/virtnetworkd does nothing. Stopping libvirtd allows virt-manager to connect. Before connection ~]# systemctl status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: disabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: active (running) since Tue 2023-06-27 11:05:46 EDT; 23min ago TriggeredBy: ● libvirtd-ro.socket ● libvirtd.socket ● libvirtd-admin.socket Docs: man:libvirtd(8) https://libvirt.org Main PID: 2859 (code=exited, status=0/SUCCESS) Tasks: 2 (limit: 32768) Memory: 29.0M CPU: 625ms CGroup: /system.slice/libvirtd.service ├─2979 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --lea> └─2980 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --lea> Jun 27 11:05:46 HPZ440.attlocal.net systemd[1]: Started libvirtd.service - Virtualization dae> Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq[2979]: started, version 2.89 cachesize 150 Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq[2979]: compile time options: IPv6 GNU-getopt DBus> Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq-dhcp[2979]: DHCP, IP range 192.168.122.2 -- 192.1> Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq-dhcp[2979]: DHCP, sockets bound exclusively to in> Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq[2979]: reading /etc/resolv.conf Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq[2979]: using nameserver 127.0.0.53#53 Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq[2979]: read /etc/hosts - 8 names Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq[2979]: read /var/lib/libvirt/dnsmasq/default.addn> Jun 27 11:05:48 HPZ440.attlocal.net dnsmasq-dhcp[2979]: read /var/lib/libvirt/dnsmasq/default> virt-manager and cockpit cannot connect to the virtual machines ~]# systemctl stop libvirtd Warning: Stopping libvirtd.service, but it can still be activated by: libvirtd-ro.socket libvirtd.socket libvirtd-admin.socket Running virt-manager then connects and works fine. ~]# systemctl status libvirtd ● libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; preset: disabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: active (running) since Tue 2023-06-27 11:29:52 EDT; 28s ago TriggeredBy: ● libvirtd-ro.socket ● libvirtd.socket ● libvirtd-admin.socket Docs: man:libvirtd(8) https://libvirt.org Main PID: 8385 (libvirtd) Tasks: 22 (limit: 32768) Memory: 62.4M CPU: 694ms CGroup: /system.slice/libvirtd.service ├─2979 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --lea> ├─2980 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --lea> └─8385 /usr/sbin/libvirtd --timeout 120 Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: internal error: Failed to start QEMU bina> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: Failed to probe capabilities for /usr/bin> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: internal error: Failed to start QEMU bina> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: Failed to probe capabilities for /usr/bin> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: internal error: Failed to start QEMU bina> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: Failed to probe capabilities for /usr/bin> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: internal error: Failed to start QEMU bina> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: Failed to probe capabilities for /usr/bin> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: internal error: Failed to start QEMU bina> Jun 27 11:29:53 HPZ440.attlocal.net libvirtd[8385]: Failed to probe capabilities for /usr/bin> Binaries that show as failing to start are for minor use processors

9 months, 3 weeks

Re: Certbot error

by Tom Horsley

On Sun, 23 Apr 2023 15:10:58 +0100 Patrick O'Callaghan wrote: > BTW 'certbot certonly ..." also failed. I'm 99% sure this is a problem > with my Apache installation. Well, the apache documentation is only 11,371 pages, so it should be easy to find :-). That's basically why I'm using dnsmasq now instead of named.

12 months

Re: what is my dns?

by Petr Menšík

bind and its named.service has no autoconfiguration that I know about. Someone has to write forwarders {} into /etc/named.conf or its included file. Whoever did that should know how has he chosen used forwarders. If that were any tool, it might have easier source file. In general there is no final DNS you can obtain. The final DNS depends on the name you query. There can be multiple layers of forwarders chained behind themselves. I think the best bet would be processing what connections offered as their name servers. nmcli without parameters might help with that. But there is no specialized tool to tell you that set of servers. General automatic tool, which could tell you for any local cache, what servers would it use for a name query, does not exist (yet). bind, unbound or dnsmasq does not provide API to create such tool. On 3/28/23 14:10, ToddAndMargo via users wrote: > On 3/28/23 00:23, Barry wrote: >> >> >>> On 28 Mar 2023, at 07:10, ToddAndMargo via users >>> <users(a)lists.fedoraproject.org> wrote: >>> >>> On 3/27/23 21:22, Tim via users wrote: >>>> Tim: >>>>>> Are you on-line? >>>>>> >>>>>> And did any of the other options work? >>>> ToddAndMargo: >>>>> No. And I am also not running sysyemd-resolved >>>> Perhaps we should go back to the start, your question is itself a bit >>>> odd. DNS means Domain Name System, but we all presume you want to >>>> know >>>> the address of your Domain Name Server. >>>> When a device joins a network it is typical that a DHCP server assigns >>>> it an addresses (numerical IP, hostname, domain name), and provides >>>> some other addresses (gateway IP, nameserver(s), subnet mask). The >>>> DHCP server need properly configuring to provide that info. Your >>>> device will glean that info, and use it, even if you are running your >>>> own name server. >>>> And one would expect that all of that gets cancelled when >>>> disconnecting >>>> (not that people often cleanly disconnect, as opposed to just losing >>>> connection). >>>> Failing that, without a DHCP server, variously named auto-config >>>> schemes can take place (Bonjour, ZeroConf, etc) which do a similar >>>> task. This time, the device, itself, self sets several of those >>>> parameters, but not in a way that can communicate outside of the >>>> network. It'll pick a random IP address from within a local-only >>>> range, it'll broadcast hostname queries waiting for an answer from >>>> anyone. >>>> Failing that, you hand set your network configuration. >>>> Normally, when you connect up to your ISP their DHCP server assigns >>>> you >>>> all that networking info. Some don't, some expect you to set some >>>> things, though that's an older way of doing things. And some just >>>> fail >>>> badly. If you want to know your ISP's DNS servers to put into your >>>> network configuration, or into your name daemon's forwarder IPs, you >>>> could try: >>>> a) Connecting via DHCP and copying the details >>>> b) Asking them what the DNS server IPs are >>>> c) Googling them >>>> Bearing in mind that an ISP's DNS servers may change, at any time, >>>> they >>>> may expect you to use DHCP to keep them current. >>>> If there's a router between your ISP and your device, *it* will have >>>> your ISP's DNS IPs in it, as your ISP's DHCP server will have >>>> configured it, and you can copy them. And *it* will probably act as >>>> your DHCP server for the rest of your network. You may be able to >>>> customise its DHCP settings to suit your LAN. That router will act as >>>> your DNS server, or simply pass queries through. You can use that >>>> router's IP as your DNS forwarder IP. >>>> You may not need to use your ISP's DNS servers, you could simply use >>>> Goggle's, or some other public DNS server (there are various public >>>> ones, with and without censoring). This may actually be better for >>>> you >>>> than your ISP's. The only gotcha is that some ISPs will give a >>>> different answer to their mailserver's IP to their own clients than to >>>> the rest of the world. >>> >>> I was looking for a way I could look up the final DNS >>> server, regardless of was type of local server I was >>> going through. >> >> To lookup a name can involves a lot of dns servers, >> not sure how many is typical but is likely 3 or more until cached >> answers exist. >> >> What do you mean by final dns server? >> >> Barry >> >> >> >> >> >>> I don't think it is possible. It looks >>> like I should dig it out from /etc/named.conf's >>> forwards section. >>> >>> # grep -i forwarders /etc/named.conf | grep -v "#" >>> forwarders { 208.67.222.123; 208.67.220.123; }; >>> forwarders {8.8.8.8; 8.8.4.4; }; >>> >>> And it looks like I have to be root to read /etc/named.conf, >>> so never mind. > > I was just trying to figure out what the DNF was when using a caching > name server: the "forwarders", without having to dig > it our of /etc/named.conf > > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

1 year

Re: what is my dns?

by Tim

On Mon, 2023-04-03 at 20:26 +0200, Petr Menšík wrote: > dnsmasq allows you to query servers using dig @localhost ch txt > servers.bind. But no other server implements it. Huh, what? "dig" comes from bind-utils, utilities for the BIND server. There's also "rndc" to twiddle with BIND from the command line. > Servers like bind, unbound or knot-resolver do not require forwarders > to work. It may work just fine even without them. They *should* always work fine without them, unless you have a peculiar ISP which interferes with normal DNS functionality. But the original poster used them on purpose, to indirectly use the internet with external censorship filtering. -- NB: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the list. The following system info data is generated fresh for each post: uname -rsvp Linux 6.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19 UTC 2023 x86_64

1 year

Re: what is my dns?

by Petr Menšík

dnsmasq allows you to query servers using dig @localhost ch txt servers.bind. But no other server implements it. There is no common way to query forwarders from any cache. unbound-control list_forwards would list forwarders defined in unbound. bind has no runtime tool to show that, just read /etc/named.conf or named-checkconf -p output. Servers like bind, unbound or knot-resolver do not require forwarders to work. It may work just fine even without them. The most universal way to obtain systemd dns servers is nmcli without parameters. It would just show what NM provides. If dnsmasq or systemd-resolved is used, it will say what were provided by the network. Whether and what local cache is using, it is cache-specific. On 3/27/23 02:27, ToddAndMargo via users wrote: > On 3/26/23 15:07, Barry wrote: >> >> >>> On 26 Mar 2023, at 22:57, ToddAndMargo via users >>> <users(a)lists.fedoraproject.org> wrote: >>> >>> Hi All, >>> >>> Fedora 37 >>> >>> I have a caching server running. Other than digging >>> out my "forward" from /etc/named.conf to figure out >>> what my DNS server is, is there a way to use "dig" >>> or other to figure out what my actual DNS server is? >> >> No as that information is not sent to the dns client. >> >> You have to look at the config in each layer of software your request >> traverses. >> >> >> Barry >> > > > Rats! Thank you for the quick response! > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

1 year

Re: No nameserver found after kernel upgrade

by Tom Horsley

On Sat, 14 Jan 2023 20:39:49 +0100 lejeczek via users wrote: > I wonder now, if it is possible, nowadays, to "bypass" > systemd's resolver - except if a separate DNS server is ran > locally. Just disable (and mask for belt and suspenders) systemd-resolved. Then edit /etc/NetworkManager/NetworkManager.conf and add dns=none after the "[main]" section, then you can remove the /etc/resolv.conf symlink and replace it with a real file you can point to your real server and network manager and systemd will leave you alone :-). I do that, plus run dnsmasq as a local dns server for my lan which picks up all the names from /etc/hosts so everyone on the local network can talk (as long as my main server is up, anyway :-). Of course, I also have to tell the DHCP on my router to inform everyone to point to my local server for DNS.

1 year, 3 months

Re: Tip: how to make your own resolv.conf

by ToddAndMargo

On 12/19/22 16:29, Chris Adams wrote: > Once upon a time, Tim <ignored_mailbox(a)yahoo.com.au> said: >> But being serious, I did start looking through the man files for the >> new networking schemes (man systemd-resolved). And supposedly, >> /etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf >> And when it is, it controls the file its linked to. > > Yeah, if you just edit /etc/resolv.conf without reading it (leaving it a > symlink to /run), your edits will get lost. All you have to do is > remove the symlink and replace it with a file, and systemd-resolved will > stop touching it (again, as documented in the file). It's not some > mystery, or difficult problem to solve, if you read the comments and > referenced documentation. > >> It is all a bit of a maze, and I don't really see how this was an >> improvement on the previous methodology. > > A single system-wide resolv.conf cannot handle more complicated setups, > such as a VPN where lookups for certain domains should be sent to a > server across the VPN. You have to run some form of local DNS server to > handle that (which could be BIND, Unbound, dnsmasq, etc.). Each of > those have their own configuration quirks that can make it more > complicated to programmatically manage, so systemd-resolved was created. I have open vpn installed. It communicates through a network bridge and the old ifcfg files. I have not used it in a while, as open vpn for Windows is corked on Windows 10 and 11. I gave up on it. I did a bug report on it, but they never fixed it. > > I'm not entirely satisfied with systemd-resolved, but it solves things > for a majority of cases. > >> Likewise with network configuration. If the previous config files >> actually did the job, why didn't they keep on using them, and just >> update the tools that set them up? > > The previous ifcfg files had many quirks, starting from being created as > shell variable lists to feed to bash scripts for network config. They > were also specific to Red Hat Linux derived OSes (e.g. Fedora, RHEL, > CentOS, etc.). NetworkManager was created to solve multiple things, one > of which was standardizing network configuration across distributions. > > The NM plugin to support the RHL-style ifcfg files has been there as a > backwards-compatibility wedge, but it was time to move on from using > that by default (and deprecate the old network-scripts pile of shell > code). Maybe some day when I have a ton of time to waste, I will try to get the official way to work.

1 year, 4 months

users search results for query "dnsmasq"