Yunohost Keeps Losing IP / IP in Diagnostic is Wrong

My YunoHost server
Hardware: Dell R720
YunoHost version: Powered by YunoHost 4.3.6 (stable).
I have access to my server : SSH, direct access
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : not really. I have a RAID server.

Description of my issue
See : After Update Server is Outside of DCHP

  • I was having issues connecting to my server after update.
  • Restarting kept giving it an address in the 216 range
  • doing sudo dhclient -r sudo dhclient gave it a correct IP address.
  • I can access this address via a browser.
  • I cannot access the http/s website
  • YNH Diagnosis ; https://paste.yunohost.org/raw/uveqonoxiy

This says that Current value: 99.83.154.118for all DNS records. However, that’s wrong. The DNS records are all set to the expected value that YNH requests

The IP you mention is in an Amazon-range. Any chance you ever ran some services on Amazon with your domain, with DNS at an external registrar as an experiment and totally forgot about it?

(

gives green light for all access, but if the diagnosis does not use your actual public IP, the results are not worth a lot.

Which IP does ping -4 to your domain give? Do you have access to a command line outside of your LAN, to exclude configuration (hosts, DNS or otherwise) in your router?

– edit – I see in your linked post that you run DNS via Cloudflare. Does your domain reseller provide DNS as well, and did an update in their panel maybe reset the DNS to their own (instead of Cloudflare)? I use dns.he.net instead of my domain reseller provided DNS, but with some actions in their (=reseller) portal, DNS gets reset to the default leading to unexpected outages.

The IP you mention is in an Amazon-range

I saw this last night, and that it was reported a couple of days ago as tied up in a bunch of spam bots so now I’m a bit worried that the system was compromised, but I can’t find anything besides that. That’s what spurred these posts.

Ping

Ping Request fails.

Cloud flare

Cloudflare does the DNS, but the actual domain is registered at another place! That might be the problem…I was going to transfer it to Cloudflare but I forgot. I’m having trouble accessing it so I emailed their help. Hopefully that’s the issue.

I really don’t know what’s going on.

WHO IS points to namecheap. Namecheaps DNS servers point to Cloudflare. Cloudflare has the various subdomain DNSes. (like archive.domain.tld). I update the IP in Cloudflare but it doesn’t seem to do anything and the IP is pointing elsewhere which is part of a spambot ring. has my server been compromised somehow? this is really bizarre.

okay it seems that the IP in cloudflare is my current IP now, but the domain URLs are not working. I can get to webadmin with the IP address but not the URL

running diagnosis gives me

The following DNS record does not seem to follow the recommended configuration:
Type: A
Name: archive
Current value: 99.83.154.118
Expected value: (actual IP)

my actual IP is the one actually set in cloudflare

99.83.154.118 was reported as of yesterday to be engaged in abusive behavior. growing increasingly concerned here :frowning:

update: okay, this is embarrassing; it seems that the domain had expired. I renewed it, but still waiting for DNS to propagate…

should I still be worried about the IP supposedly engaging in a spam network, or will that resolve now that my DNS will point to the right IP?

1 Like

Difficult to say, maybe the “abusive behavior” was “sending emails using an unregistered domain” … but could be something else. Unfortunately, entities flagging “abusive behavior” tend to never give the slightest clue about that exactly is the “abusive behavior” …

1 Like

thanks.

I still seem to be having the issue that when the server reboots it doesn’t get the Ip right. I have to run sudo dhclient -r and then sudo dhclient for it to appear in my LAN. As a result I’ve not been able to test the DNS yet (have to take the monitor off my computer and walk it over to the closet where the server is every time).

That should not be necessary. Your router can show you which IP your Yunohost received via DHCP, then you can reach it over the LAN and replace it.
It might be worthwhile to check whether the router got some option that means ‘always give this device the same IP’, or to set the Yunohost to a fixed IP. The first option is most flexible.

To test your webapps, you could temporarily set the domains in your laptop/desktop hosts file (/etc/hosts on Unix-like systems, Windows got it somewhere in a Windows-subdirectory of the same name), because via the IP, as you found, only the admin interface is reachable.

I bought a little mini-monitor today to make this easier, and then redid the DCHP and then everything works again! However, when I restart I lose the IP again. So it seems that there were/are two issues:

  1. My domain expired so the DNS and the forwarding got all weird. This is fixed. Huge thanks to you for pointing out that issue!

  2. The original issue from here.

Basically yunohost starts up and says something like public ip: (no ip detected?) and doesn’t show up on the LAN until I login and then do the dhclient stuff.

It might be worthwhile to check whether the router got some option that means ‘always give this device the same IP’, or to set the Yunohost to a fixed IP. The first option is most flexible.

This is set up, the IP is static. Just that either

  1. YNH does not request or get an IP
  2. the router does not receive or give YNH a IP without refreshing DCHP.

I suspect it’s YNH because this router has been performing fine. It could probably use a wifi update but YNH is connected directly to ethernet. (I have also tried changing the ethernet cable, no difference there)

I just noticed, you got quite a nice machine running Yunohost; don’t the R720’s have a management interface for DRAC? You already have the monitor now, but it would save you from getting up from your chair :stuck_out_tongue:

After a restart, does it not have any IP at all, no IPv4 and no IPv6? Perhaps something in systemd is off, and it starts DHCP before the network is ready. Lets discuss that in the other thread so you can mark this one solved and not muddle the discussion :wink:

– Edit – I see you already marked the other thread solved with the temporary workaround. As long as you don’t reboot too often, there are other things with more priority I’d say. Perhaps have a look into the boot log with dmesg or journalctl.

My Yunohost has a first mention of dhclient in the boot log before the first mention of ifup, and there are some warnings and errors, but it does get an IP in about a second:

Jan 13 04:41:11 online dhclient[122]: Internet Systems Consortium DHCP Client 4.4.1
Jan 13 04:41:11 online ifup[97]: Internet Systems Consortium DHCP Client 4.4.1
Jan 13 04:41:11 online dhclient[122]: Copyright 2004-2018 Internet Systems Consortium.
Jan 13 04:41:11 online ifup[97]: Copyright 2004-2018 Internet Systems Consortium.
Jan 13 04:41:11 online dhclient[122]: All rights reserved.
Jan 13 04:41:11 online ifup[97]: All rights reserved.
Jan 13 04:41:11 online dhclient[122]: For info, please visit https://www.isc.org/software/dhcp/
Jan 13 04:41:11 online ifup[97]: For info, please visit https://www.isc.org/software/dhcp/
Jan 13 04:41:11 online dhclient[122]: 
Jan 13 04:41:11 online dhclient[122]: /etc/dhcp/dhclient.conf line 57: no option named name in space dhcp
Jan 13 04:41:11 online dhclient[122]: supersede name ""
Jan 13 04:41:11 online dhclient[122]:            ^
Jan 13 04:41:11 online ifup[97]: /etc/dhcp/dhclient.conf line 57: no option named name in space dhcp
Jan 13 04:41:11 online ifup[97]: supersede name ""
Jan 13 04:41:11 online ifup[97]:            ^
Jan 13 04:41:11 online dhclient[122]: /etc/dhcp/dhclient.conf line 57: semicolon expected.
Jan 13 04:41:11 online dhclient[122]: 
Jan 13 04:41:11 online dhclient[122]: ^
Jan 13 04:41:11 online ifup[97]: /etc/dhcp/dhclient.conf line 57: semicolon expected.
Jan 13 04:41:11 online ifup[97]: ^
Jan 13 04:41:11 online systemd[1]: Started Create Volatile Files and Directories.
Jan 13 04:41:11 online dhclient[122]: Listening on LPF/eth0/b0:de:eb:5a:26:68
Jan 13 04:41:11 online ifup[97]: Listening on LPF/eth0/b0:de:eb:5a:26:68
Jan 13 04:41:11 online ifup[97]: Sending on   LPF/eth0/b0:de:eb:5a:26:68
Jan 13 04:41:11 online ifup[97]: Sending on   Socket/fallback
Jan 13 04:41:11 online ifup[97]: DHCPREQUEST for 192.168.1.30 on eth0 to 255.255.255.255 port 67
Jan 13 04:41:11 online dhclient[122]: Sending on   LPF/eth0/b0:de:eb:5a:26:68
Jan 13 04:41:11 online dhclient[122]: Sending on   Socket/fallback
Jan 13 04:41:11 online dhclient[122]: DHCPREQUEST for 192.168.1.30 on eth0 to 255.255.255.255 port 67
Jan 13 04:41:11 online dhclient[122]: DHCPACK of 192.168.1.30 from 192.168.1.1
Jan 13 04:41:11 online ifup[97]: DHCPACK of 192.168.1.30 from 192.168.1.1
Jan 13 04:41:11 online ifup[97]: suspect value in domain_search option - discarded
Jan 13 04:41:11 online dhclient[122]: suspect value in domain_search option - discarded
Jan 13 04:41:12 online dhclient[122]: Error printing text.
Jan 13 04:41:12 online ifup[97]: Error printing text.
Jan 13 04:41:12 online dhclient[122]: bound to 192.168.1.30 -- renewal in 3078 seconds.
Jan 13 04:41:12 online uwsgi[128]: [uWSGI] getting INI configuration from /etc/uwsgi/apps-available/ffsync.ini
Jan 13 04:41:14 online ifup[97]: Waiting for DAD... Done
Jan 13 04:41:14 online systemd[1]: Started Raise network interfaces.
Jan 13 04:41:14 online systemd[1]: Reached target Network.

I took non-dhclient and non-ifup lines out, it was not so neatly in a row.

For IPv6 I set a fixed IP. Not sure whether that is best practice, but it was easier to do that than to find out where to configure fixed DHCP assignments for IPv6; I didn’t look for the IPv6 bit in the log.

In case you do receive an IP, does ip -4 route make any sense?

If there are some clues and you want to continue investigating, perhaps make a new thread for it.

nice machine

it’s alright! i got it in a very nice deal :slight_smile: I am an archivist so I need a lot of space and computing power :slight_smile:

R720’s have a management interface for DRAC

the DRAC management interface has been broken on all modern browsers for awhile… I found this guide to fix it after hours of searching once but it is a bit high level for me :frowning: IDRAC6 Virtual Console Launcher · GitHub

If there are some clues and you want to continue investigating, perhaps make a new thread for it.

I’ll try to get all the infomation together (ip -4 and the journalctl) and make a post this weekend—the week has been too chaotic so far!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.