Re: Please help me with samba or my brain will explode.
On Tue, 2018-02-13 at 09:08 +, Илья Коскин wrote: > path statement should not be specified in [homes] section, this is samba > built in section, to > dynamically share user home directories. > > I am not logged in as kasak, samba users is not the same as system users. To > login as kasak, first I > need to add kasak to samba with smbpasswd -a kasak, or samba-tool user add > kasak. But I have not added > kasak to samba, so when smbclient tries to login as kasak it doesn't find it > and falls back to guest > (unix nobody) account, because i have option "Map to guest=Bad user" in my > config. > > Look: > [kasak@kasakoff ~]$ smbclient kasakoff\\Share > Enter WORKGROUP\kasak's password: > Try "help" to get a list of possible commands. > smb: \> ^Z > [1]+ Остановленsmbclient kasakoff\\Share <<< ctrl+z > > [kasak@kasakoff ~]$ sudo smbstatus > [sudo] пароль для kasak: > > Samba version 4.7.5 > PID Username GroupMachine > Protocol > Version Encryption Signing > -- > -- > 8027nobody nobody 192.168.2.87 > (ipv4:192.168.2.87:12209)SMB2_10 -- > > 8001nobody nobody 192.168.3.251 > (ipv4:192.168.3.251:36734) SMB3_11 -- > <<< my ip > > Service pid Machine Connected at > Encryption Signing > - > IPC$ 8027192.168.2.87 Вт фев 13 12:07:01 2018 MSK -- > > Share8001192.168.3.251 Вт фев 13 12:06:46 2018 MSK -- > > > No locked files > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org Does running smbd in a terminal tell you more? systemctl stop smbd.service smbd -F -S -d 2 Had to do this yesterday - it helped me fix a problem ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: NetworkManager-wait-online is still utterly, and completely, broken
On Tue, 2017-12-19 at 17:37 -0500, Sam Varshavchik wrote: > Justin Moore writes: > > > I interpret "-s" to mean "all interfaces are active but do not necessarily > > have an address or a default route". This means that NM will return success > > What does it mean for an interface that has a static IP address explicitly > specified in its ifcfg file to be "active", but not have that IP address? > > > The problem with the former is that it can return before your system can > > reach the outside world (e.g., interface is up but doesn't have a DHCP- > > The interface in question has a static IP address. DHCP is not in the > picture. > > But an argument can be made that even if a network interface is configured > via DHCP, then it's not "active" until it succeeds in acquiring an IP > address. But that's besides the point, because these are simple, garden > variety, static IP addresses. Can be any simpler than that. > > Furthermore, I distinctly recall incidents where something got fubared with > my DHCP server, and I had to drink a cup of coffee before other servers > finished booting. > > It's been my experience that NetworkManager most definitely puts the brakes > on booting the server if dhclient can't get an IP address. > > So, given that it throws a tantrum if dhclient can't get an IP address, I'm > quite puzzled that it also just blows past an network port with a static IP > address, but before it is fully configured with that IP address. This does > not compute. > > > assigned address). The problem with the latter is that if your system has > > multiple interfaces, as soon as *one* of them has an address and a route, > > NM > > says all is well and continues, *even if that interface can't reach the > > That's not how the nm-online man page describes the -s option. If that's not > what the -s option does, then I have no idea what it's supposed to be doing. > > > along before my actual network interface got an address. This caused issues > > > > with various services, and -- if you check the mythtv-users archives -- > > you'll see that the systemd people's response was "working as intended, > > that's a bug in mythtv and the other pieces of software which don't adapt > > to > > network interfaces which appear and disappear randomly." > > Well, I wouldn't really expect any less flippant or arrogant response there, > this does not surprise me. But that's not important. > > What is important, is that it's an inescapable conclusion that the only > workable solution for this mess is something on the order of my script that > routes around the damage, and beats systemd in submission. It's horribly > ugly, I'm embarassed that I actually had write such a clunker, but it seems > to actually makes network-online.target do what it's supposed to be doing in > the first place, but is apparently too complicated for either systemd, or > NetworkManager, to do correctly on their own. > > So be it. Life's too short. > I think I have tracked down my problem with the help of nm-wait-online-routes-gw.conf ! I have no explanation as to why this has started happening after recent updates. I had to turn the .conf into a script to get it to work - finger trouble I expect. ja@hayling NetworkManager-wait-online.service.d 4$ cat script.conf [Unit] [Service] ExecStart=/usr/bin/ja_nm-online.sh [Install] ja@hayling NetworkManager-wait-online.service.d 6$ cat /usr/bin/ja_nm-online.sh #!/bin/bash # "LF=$'\n'; "' \ ROUTES=" \ default \ 148.197.29.0/24 \ "; \ GW=148.197.29.5; \ Not a Gateway but my server I beleive my NFS "failures" are caused by the VMware network interfaces "sometimes" coming up before the "real" network interfaces. (VMware Workstation 14 uses its own DHCP server not my DHCP server) nm-online -s takes the vmware interfaces as a "working network". nm-online (no -s) does not. This "boot" would probably have caused an NFS mount failure Just two interfaces up - before DHCP to my server has run. Dec 20 13:35:50 hayling.jaa.org.uk NetworkManager[1035]: [1513776950.6441] manager: startup complete Dec 20 13:35:50 hayling.jaa.org.uk ja_nm-online.sh[1344]: 172.16.91.0/24 dev vmnet8 proto kernel scope link src 172.16.91.1 Dec 20 13:35:50 hayling.jaa.org.uk ja_nm-online.sh[1344]: 192.168.111.0/24 dev vmnet1 proto kernel scope link src 192.168.111.1 Dec 20 13:35:51 hayling.jaa.org.uk kernel: e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Dec 20 13:35:51 hayling.jaa.org.uk kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s31f6: link becomes ready ... Later all interfaces are up - after DHCP to my server has run Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: default via 148.197.29.254 dev enp0s31f6 proto static metric 100 Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: 148.197.29.0/24 dev enp0s31f6 proto kernel scope link src 148.197.29.202 metric 100 Dec 20 13:35:
Re: NetworkManager-wait-online is still utterly, and completely, broken
On Tue, 2017-12-19 at 07:16 -0500, Sam Varshavchik wrote: > Gordon Messmer writes: > > > On 12/18/2017 05:52 AM, Sam Varshavchik wrote: > > > Time IP addresses > > > == > > > 08:35:34 > > > 08:35:35 192.168.0.1 > > > > > > At 08:35:34 the server had no IP addresses > > > > > > Well, it probably had 127.0.0.1, which brings into question what the > > complete state of the network was. > > > > Could you arrange to execute "ip addr show | logger" in your unfrak script? > > > > That way we get all of the interfaces and all of the addresses regardless > > of > > family. > > > > Could you also see if removing the "-s" flag from > > /usr/lib/systemd/system/NetworkManager-wait-online.service changes the > > behavior of the system? > > Running just "ip addr show | logger" was not conclusive. Looks like the > overhead of doing so delays things long enough so even the first time this > actually runs all the network interfaces have their IP addresses already > assigned. > > Removing the -s option from actually makes things worse. The script has to > wait noticably longer before all IP addresses are assigned: > > Subject: systemd network initialization unfrak report > > Time IP addresses > == > 06:52:56 > 06:52:57 > 06:52:58 > 06:52:59 192.168.0.1 > > Usually it's 1 or 2 seconds. Without the -s option it's 4-5 seconds. > > This seems consistent with the description of what the -s option does, from > the man page. The way I parse its man page entry is that the -s option > actually waits for more things to happen, before it's done. So removing that > option makes NetworkManager's definition of when things are online occur > much earlier. > > This is confirmed by running "ip addr show | logger" without -s option. This > produces some useful results. This time, the first time "ip addr show" runs > it's early enough so that the network is not fully initialized. > > syslog shows two runs of "ip addr show", showing no IP addresses configured > on one of the two network interfaces. The 2nd network interface already has > its IP addresses assigned. This is followed by some messages from > NetworkManager, then another run of "ip addr show", showing all network > interfaces with assigned IP addresses. > > emd[1]: Started Unfrak systemd network startup. > > Note that "ip addr show" ran as part of the script that has a dependency on > nm-line. > > After reversing all changes, putting the -s option back in, and not running > "ip addr", repeated boots shows the status quo being restored. The presence > of the -s option reduces the additional time that the script needs to wait > for all IP addresses to be assigned to 1 or 2 seconds. But it still has to > wait, since nm-online -s -q returns too early. > > I have read the nm-online man page about 10 times and I am still not clear what it is telling me. If your interpretation is correct I do not understand how removing the -s option solves my NSF mount problem. Aside: I have confirmed on a second machine that with the -s option present sometimes the NFS mount fails. First 10 boots no mount failuresaha I thought! Second 10 boots 2 mount failures ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: NetworkManager-wait-online is still utterly, and completely, broken
On Mon, 2017-12-18 at 19:24 -0500, Sam Varshavchik wrote: > Gordon Messmer writes: > > > On 12/18/2017 05:52 AM, Sam Varshavchik wrote: > > > Time IP addresses > > > == > > > 08:35:34 > > > 08:35:35 192.168.0.1 > > > > > > At 08:35:34 the server had no IP addresses > > > > > > Well, it probably had 127.0.0.1, which brings into question what the > > complete state of the network was. > > I'm pretty sure it does. My script only checks the IP addresses it knows > about. It doesn't check loopback. > > > Could you arrange to execute "ip addr show | logger" in your unfrak script? > > > > That way we get all of the interfaces and all of the addresses regardless > > of > > family. > > > > Could you also see if removing the "-s" flag from > > /usr/lib/systemd/system/NetworkManager-wait-online.service changes the > > behavior of the system? > > I'll do this at the first convenient opportunity. > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org I have now tried to do some sensible testing with the -s option in /usr/lib/systemd/system/NetworkManager-wait-online.service I have tested in groups of 10 reboots in the order shown A fail indicating that the NFS mount has failed with -s2 fails in 10 no -s0 fails in 10 with -s3 fails in 10 no -s0 fails in 10 no -s0 fails in 10 with -s4 fails in 10 I have not seen a single failure with the -s removed Hence my immediate problem appears to be solved! Many thanks ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: NetworkManager-wait-online is still utterly, and completely, broken
On Mon, 2017-12-18 at 09:56 -0700, stan wrote: > On Mon, 18 Dec 2017 07:19:02 -0500 > Sam Varshavchik wrote: > > > When we had initiscripts, I forget which one it was, but there was > > one that read all the config files, and enabled those interfaces. And > > stuff that depended on the network being up ran after that. Simple. > > Easy. So, again: is it unreasonable to be able to start things that > > require the statically- assigned IP addresses after they actually are > > assigned to their network ports? Did something change, in the world > > we live in, where this is not possible any more? And what exactly did > > change, that made this a logically impossible, herculean task? > > I think you are talking about the days before we had multi-threaded > boot, and boot was deterministic. Boot went to multi-threaded, and so > became non-deterministic, in order to shorten boot time. Maybe > part of the solution is a kernel (or systemd) switch that says, "I > don't care if boot takes 10 or 20 seconds (or a minute) longer, I want > it to be deterministic." If that switch was set, then things would > always run sequentially in a fixed order, unlike now. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org Many thanks for the suggestions & feedback AFAIK I have not changed anything and I cannot get the machine to fail again with the problem of DHCP running after the nfs mount attempts. Yesterday I could not get it to boot cleanly in about 10 attempts! Maybe it was a network problem, maybe a hardware problem? Maybe some form of race condition with NetworkManager-wait-online and friends I will bring a second F27 machine up to the same "update" state and see what happens ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: NetworkManager-wait-online is still utterly, and completely, broken
On Sun, 2017-12-17 at 08:20 -0500, Tom Horsley wrote: > On Sun, 17 Dec 2017 11:07:52 + > Dr J Austin wrote: > > > Anyone else with the same problem/ > > I gave up on getting NFS mounts to work a long time ago. > I have a job I start with "at now" in rc.local that > delays for a few seconds then does all the NFS mounts. > I have other commands in there as well to delay the > start of other services that need the network and > often don't come up correctly in a normal boot. > > P.S. The use of "at now" is required by yet more > stupidity introduced by systemd which seems to believe > it desperately needs to keep track of everything > started by rc.local despite the fact that rc.local > has always been a place to put ad-hoc random junk. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org I gave up using ldap/autofs some time ago and until the last update the _netdev option in fstab (or something else maybe) has been working perfectly. 148.197.29.5:/home /home nfs4defaults,_netdev0 0 148.197.29.5:/global/global nfs4defaults,_netdev0 0 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: NetworkManager-wait-online is still utterly, and completely, broken
On Sat, 2017-12-16 at 10:03 -0500, Sam Varshavchik wrote: > Just had another boot that utterly failed because services that were > supposed to start only after the network interfaces came up, didn't. They > started too soon. Privoxy's logfile has the smoking gun: > > 2017-12-16 09:42:39.875 7f4acdaa6740 Fatal error: can't bind to > 192.168.0.1:8000: Cannot assign > requested address > > This is despite that NetworkManager-wait-online was enabled and active. This > is what everyone kept telling me was the only thing that needed to be done. > Well, it was enabled: > > [root@shorty system]# systemctl status NetworkManager-wait-online > ● NetworkManager-wait-online.service - Network Manager Wait Online >Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait- > online.service; e >Active: active (exited) since Sat 2017-12-16 09:42:39 EST; 12min ago > Docs: man:nm-online(1) > Process: 977 ExecStart=/usr/bin/nm-online -s -q --timeout=30 (code=exited, > sta > Main PID: 977 (code=exited, status=0/SUCCESS) > Tasks: 0 (limit: 4915) >CGroup: /system.slice/NetworkManager-wait-online.service > > Dec 16 09:42:32 shorty.email-scan.com systemd[1]: Starting Network Manager > Wait > Dec 16 09:42:39 shorty.email-scan.com systemd[1]: Started Network Manager > Wait O > > It came up at 09:42:39. And, at 09:42:39 privoxy also came up. And privoxy > still blew chunks because the primary network interface wasn't up yet. > > Why is it so friggin difficult to get something this simple, this basic > concept of starting things only after the network interfaces are up, working > correctly, and reliably? > > Oh yeah, I know. systemd. > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org Similar problem here Latest updates mean that my nfs mounts in /etc/fstab fail on boot because network is said to be running before DHCP has sorted itself out! This assumes I am interpreting journalctl output correctly. Dec 16 13:26:33 hayling.jaa.org.uk NetworkManager[1148]: [1513430793.6518] manager: startup complete Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Started Network Manager Wait Online. Dec 16 13:26:33 hayling.jaa.org.uk audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-wait-online comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Reached target Network is Online. < Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Mounting /global... Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Starting Notify NFS peers of a restart... Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Mounting /home... Dec 16 13:26:33 hayling.jaa.org.uk sm-notify[2847]: Version 2.2.1 starting Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Started Notify NFS peers of a restart. Dec 16 13:26:33 hayling.jaa.org.uk audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=rpc-statd-notify comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 16 13:26:33 hayling.jaa.org.uk kernel: FS-Cache: Loaded Dec 16 13:26:33 hayling.jaa.org.uk kernel: FS-Cache: Netfs 'nfs' registered for caching Dec 16 13:26:33 hayling.jaa.org.uk kernel: Key type dns_resolver registered Dec 16 13:26:33 hayling.jaa.org.uk kernel: NFS: Registering the id_resolver key type Dec 16 13:26:33 hayling.jaa.org.uk kernel: Key type id_resolver registered Dec 16 13:26:33 hayling.jaa.org.uk kernel: Key type id_legacy registered Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: global.mount: Mount process exited, code=exited status=32 Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Failed to mount /global. Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Dependency failed for Remote File Systems. Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'. Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: global.mount: Unit entered failed state. Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: home.mount: Mount process exited, code=exited status=32 Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: Failed to mount /home. Dec 16 13:26:33 hayling.jaa.org.uk systemd[1]: home.mount: Unit entered failed state. 1 second later??!!! ... Dec 16 13:26:34 hayling.jaa.org.uk NetworkManager[1148]: [1513430794.4301] device (enp0s31f6): state change: config -> ip-config (reason 'none', internal state 'managed') Dec 16 13:26:34 hayling.jaa.org.uk NetworkManager[1148]: [1513430794.4306] dhcp4 (enp0s31f6): activation: beginning transaction (timeout in 45 seconds) Dec 16 13:26:34 hayling.jaa.org.uk NetworkManager[1148]: [1513430794.4383] dhcp4 (enp0s31f6): dhclient started with pid 2886 Dec 16 13:26:34 hayling.jaa.org.uk d
Re: I give up, no change to bring VMware Workstation running after F25->F26 upgrade ...
On Mon, 2017-07-31 at 10:04 +0200, Walter H. wrote: > On Sun, July 30, 2017 21:14, Dr J Austin wrote: > > > > Assuming you are running the linux version of WS 12.5.7 > > and F26 kernel 4.11.11-300.fc26.x86_64 > > Then I have w2k and windows 7 working > > > > Have you found this > > http://rglinuxtech.com/?p=1992 > > yes and didn't work, > only the virtual network adapters for NAT or Host-Only Guests worked ... > Strange - mine is using auto-bridging OK > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: I give up, no change to bring VMware Workstation running after F25->F26 upgrade ...
Assuming you are running the linux version of WS 12.5.7 and F26 kernel 4.11.11-300.fc26.x86_64 Then I have w2k and windows 7 working Have you found this http://rglinuxtech.com/?p=1992 I followed the above URL Sorting out the libraries cp -r /usr/lib/vmware-installer/2.1.0/lib/lib/libexpat.so.0 /usr/lib/vmware/lib cd /usr/lib/vmware/lib/libz.so.1 mv -i libz.so.1 libz.so.1.old ln -s /usr/lib64/libz.so.1 . vmware --- Compiling the vmmon & vmnet modules mkdir /lib/modules/`uname -r`/misc cd /usr/lib/vmware/modules/source tar xf vmmon.tar tar xf vmnet.tar cd vmmon-only make cd ../vmnet-only make cp /usr/lib/vmware/modules/source/vmmon-only/vmmon.ko /lib/modules/`uname -r`/misc cp /usr/lib/vmware/modules/source/vmnet-only/vmmon.ko /lib/modules/`uname -r`/misc depmod -a In addition I had to disable 3D acceleration for the w7 virtual machine On Sun, 2017-07-30 at 17:12 +, Zachary Snyder wrote: > You are trying to get VMware running on linux to host windows or vice versa? > If you're trying to host > windows inside linux is KVM/Qemu > > On Sun, Jul 30, 2017 at 1:10 PM Walter H. wrote: > > tried VMware Wkst. 12.5.6, also 12.5.7 ... no change ... > > even the hack to get the additional virtual network interfaces, nothing > > helped ... > > > > maybe the next release of VMware Wkst. 12.5.8 will run ... > > > > as VMware Wkst. is essential for me, there is no way having Linux > > instead of Windows; > > the decision to try it with Fedora is the feature of inplace upgrade and > > keep it up-to-date ... > > > > I'll keep my old windows running as log as the hardware is working ... > > > > ___ > > users mailing list -- users@lists.fedoraproject.org > > To unsubscribe send an email to users-le...@lists.fedoraproject.org > > -- > sa...@fedoraproject.org > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: Xfce on Fedora 24?
On Mon, 2016-08-08 at 01:05 -0400, Jon LaBadie wrote: > On Sun, Aug 07, 2016 at 11:50:14PM -0400, Robert Moskowitz wrote: > > > > I have set up a system with F24 and installed Xfce. My old system is > > running F22 with Xfce, so a bit of a jump. > > > > But on a lot of dialogs it is saying that Cinnamon is running? > > > > Apps are different like Nemo rather than Thudar? > > > > System tray on the bottom not top and a few other oddities. > > > > Did I really get Xfce? Has it changed that much? > > > > I'm sure there are others, but here are two suggestions. > > I notice for 4 environments on my F24 system (gnome, mate, > plasma, and cinnamon), each set the environment variable > DESKTOP_SESSION. Unfortunately I don't have xfce installed > to check it. > > At the login screen, after your user id is selected or > typed in, but before entering your password, look for > an icon that drops down a menu of available desktop > environments. It will default to your most recent > session and you can select a different one if desired. > > Jon This may be worth a try From my first F24 install (XFCE) notes - some time ago lightdm would not select XFCE as the window manager and it was necessary to "dnf remove cinnamon" John -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
F23 Recent upgrade - autofs, ldap, sssd problem
Hi Following the upgrade today autofs no longer mounts the maps provided by openldap The error is setautomntent: lookup(sss): setautomntent: No such file or directory [root@hayling:/var/log]$ systemctl status autofs -l ● autofs.service - Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/autofs.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2016-06-03 09:50:16 BST; 15min ago Process: 4326 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid (code=exited, status=0/SUCCESS) Main PID: 4330 (automount) CGroup: /system.slice/autofs.service └─4330 /usr/sbin/automount --pid-file /run/autofs.pid Jun 03 09:50:16 hayling.jaa.org.uk systemd[1]: Starting Automounts filesystems on demand... Jun 03 09:50:16 hayling.jaa.org.uk automount[4330]: setautomntent: lookup(sss): setautomntent: No such file or directory Jun 03 09:50:16 hayling.jaa.org.uk systemd[1]: Started Automounts filesystems on demand. Googling finds https://bugzilla.redhat.com/show_bug.cgi?id=1189767 It would appear to have been an intermittent problem on my systems (I assume at boot time) for some time as shown by journalctl However with the latest upgrade it is a winner every time! (Not just at boot time) [root@hayling:/var/log]$ journalctl -u autofs-- Reboot -- ... Jun 03 09:18:54 hayling.jaa.org.uk systemd[1]: Starting Automounts filesystems on demand... Jun 03 09:18:54 hayling.jaa.org.uk automount[1737]: setautomntent: lookup(sss): setautomntent: No such file or directory Jun 03 09:18:54 hayling.jaa.org.uk systemd[1]: Started Automounts filesystems on demand. Jun 03 09:20:20 hayling.jaa.org.uk systemd[1]: Stopping Automounts filesystems on demand... Jun 03 09:20:20 hayling.jaa.org.uk systemd[1]: Starting Automounts filesystems on demand... Jun 03 09:20:21 hayling.jaa.org.uk automount[2049]: setautomntent: lookup(sss): setautomntent: No such file or directory Jun 03 09:20:21 hayling.jaa.org.uk systemd[1]: Started Automounts filesystems on demand. Jun 03 09:27:49 hayling.jaa.org.uk systemd[1]: Stopping Automounts filesystems on demand... Jun 03 09:27:50 hayling.jaa.org.uk systemd[1]: Starting Automounts filesystems on demand... Has anyone else seen this problem become worse recently? John -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: dovecot? systemd?
Is portreserve installed and doing things? I had the opposite problem with Centos 6.7 dovecot was grabbing the port when I didn't want it to From my DIY notes To cure the /etc/portreserve/dovecot problem on maui the immutable bit has been set on an empty file chattr +i /etc/portreserve/dovecot On Thu, 2016-02-11 at 10:16 -0500, Tom Horsley wrote: > On Thu, 11 Feb 2016 22:05:32 +0800 > Ed Greshko wrote: > > > If you are certain the problem arose after the most recent update then the > > logical thing > > to do is list what was updated. > > I'm not certain of anything any more :-). > > I rebooted twice after the update and dovecot failed each time, so it seemed > to be reproducible, but then I added a "netstat -n -l -p" command to > dovecot's "pre start" script so I could see who has port 993 tied up > when dovecot starts, and it has worked perfectly after the reboots > I tried with the modified the script. > > I haven't yet tried putting back the original script to see if it > starts failing again because I'm tired of rebooting :-). -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: F23 does not renew dhcp leases correctly and corrupts DDNS
On Thu, 2016-01-28 at 15:18 -0500, Bill Shirley wrote: > > On 1/25/2016 10:35 PM, Tim wrote: > > Allegedly, on or about 25 January 2016, Greg Woods sent: > > > (I can't remember how to get a dump of the zone, but I remember doing > > > it in the past. > > Simply stopping the nameserver ought to cause it to reconcile its > > records on file. That's what I do when I've struck a DNS/DHCP foul-up. > > Stop DHCP server, Stop BIND, edit records, increment the serial number, > > restart BIND, restart DHCP server. > > > > > Try using: > rndc freeze example.com > edit the zone > rndc thaw example.com > > If you are using DNS views: > rndc freeze example.com in > edit the zone > rndc thaw example.com in > > Don't forget to increment the serial no. > > You don't have to stop DNS or DHCP. > > Bill > -- Thanks for the feedback I've hacked together a script to do as you suggest whilst I'm experimenting to try and find out how/why my server became/becomes corrupted. I now think it is to do with the way I cloned these particular client machines. I used a variation of Create a valid F23 master machine/SSD and dump it whilst unmounted ... dump 0f /mnt/zip/F22_dump_2015_06_22 /dev/sdb5 ... Restore to the disk/SSD of another machine restore -rf /mnt/zip/F22_dump_2015_06_22 (This took less than 120s) ... mount /dev/sda6 /mnt/zip mount -o bind /dev /mnt/zip/dev mount -o bind /proc /mnt/zip/proc mount -o bind /sys /mnt/zip/sys chroot /mnt/zip gedit /etc/fstab gedit /etc/hostname Sort out grub2 I used to gedit /etc/sysconfig/network-scripts/ifcfg-eno1 but recently I have been lazy and let NM "sort it out" - for F23 I think it/I didn't get it quite right! Adding an extra "mount -o bind /run /mnt/zip/run" to the list above lets me use nmcli in the chroot environment but it is not quite clear to me exactly what to do at that stage! John -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: F23 does not renew dhcp leases correctly and corrupts DDNS
On Tue, 2016-01-26 at 14:05 +1030, Tim wrote: > Allegedly, on or about 25 January 2016, Greg Woods sent: > > (I can't remember how to get a dump of the zone, but I remember doing > > it in the past. > > Simply stopping the nameserver ought to cause it to reconcile its > records on file. That's what I do when I've struck a DNS/DHCP foul-up. > Stop DHCP server, Stop BIND, edit records, increment the serial number, > restart BIND, restart DHCP server. > > That sort of thing tends to happen when you're experimenting, and > haven't invented a new IP outside of the DHCP pool. > > e.g. If your LAN uses 192.168.0.0, then set aside a range to be dynamic, > such as 192.168.0.1 to 192.168.0.100, and configure your DHCP server to > only dole out those addresses to dynamic clients. For static addresses, > whether individually set on the client equipment, or handed out as fixed > DHCP addresses, use IPs outside of that range. > > Other things that confuse DHCP/DNS server combinations are dual-boot > PCs, where on one OS the DHCP client sends out prefix codes that the > other does not, and the DHCP server looks at those codes as well as MAC > addresses, and doesn't give the same PC the same address for each OS. > Which is logical enough, except that it doesn't properly reset the one > it'd previously doled out to the same PC. It gets truly messy if the PC > uses the same hostname on both OSs. I've seen reverse IP records stay > stale, and forward ones updated. > > > -- > [tim@localhost ~]$ uname -rsvp > Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 > > Boilerplate: All mail to my mailbox is automatically deleted, there is > no point trying to privately email me, I only get to see the messages > posted to the mailing list. > > I'd just like to say that vinyl record crackles and pops are far less > annoying than digigigigital mu-u-u-u-usic hiccicicicups and > yooo-u tu-be ... pauses. > > > Thank you for the replies I am working on a small network and hence I can reset the dhcp/ddns to "Zero" - I have a script that does this. I added my experiences to https://bugzilla.redhat.com/show_bug.cgi?id=1269093 and received a very prompt reply from Dan Williams I have tested out the use of the two commands nmcli con mod eno1 connection.autoconnect no nmcli con mod eno1 connection.autoconnect yes and by magic the client no longer issues DHCPDISCOVER every time NetworkManager is restarted and hence does not request and obtain a new IP address. I also checked what happened when the leases ran out naturally by setting "default-lease-time 300;" in dhcpd.conf on the server Again all was well I have not yet worked out how often the magic incantation is required - once after a new installation or once before the lease runs out or ... Aside: I suspect that originally the client may not have been deleting the old IP address from the interface but was adding the new IP as a "secondary". At one stage during testing "ip a s" gave multiple entries of the form inet 148.197.29.133/24 brd 148.197.29.255 scope global dynamic eno1 This might explain my original symptoms - after several days the client and server would both freeze with the network busily flashing away. The only way out was to press the button on all machines. I originally thought it was a hardware problem but now suspect that NetworkManager may have been the cause of the crashes. At least my machines, router, switches, cables, ... have all been cleaned and dusted! A nasty little problem as I have been happily running my arrangement for 10 years or more! -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
F23 does not renew dhcp leases correctly and corrupts DDNS
I am running an F23 machine (paxos) with a C6.7 dhcp/ddns server (maui) - both
fully updated
I have the ability to "RESET" the dhcp/ddns to a default condition on the
server(maui)
Aside
I have another F23 client (naxos) that has NOT been fully updated and works
correctly
I also have an Android smart phone that works correctly and updates the DNS
whenever it is reconnected or powered up.
Following a "RESET" of the server and a clean boot of an F23 client (paxos)
things are fine - the client (paxos) shows dhclient running with the lease file
listed
and server (maui) messages are as shown
First boot from clean - hdclient is running on paxos
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf
/var/run/dhclient-eno1.pid \
-lf
/var/lib/NetworkManager/dhclient-37107b25-12bf-4de0-935e-12b9b6062fb4-eno1.lease
\
-cf /var/lib/NetworkManager/dhclient-eno1.conf eno1
[root@paxos:~]$ ls -l
/var/lib/NetworkManager/dhclient-37107b25-12bf-4de0-935e-12b9b6062fb4-eno1.lease
-rw-r--r--. 1 root root 521 Jan 25 09:54
/var/lib/NetworkManager/dhclient-37107b25-12bf-4de0-935e-12b9b6062fb4-eno1.lease
[root@paxos:~]$ cat
/var/lib/NetworkManager/dhclient-37107b25-12bf-4de0-935e-12b9b6062fb4-eno1.lease
default-duid "\000\001\000\001\0368\255;x$\257:~:";
lease {
interface "eno1";
fixed-address 148.197.29.130;
option subnet-mask 255.255.255.0;
option routers 148.197.29.254;
option dhcp-lease-time 86400;
option dhcp-message-type 5;
option domain-name-servers 148.197.29.5,212.104.130.9;
option dhcp-server-identifier 148.197.29.5;
option broadcast-address 148.197.29.255;
option domain-name "jaa.org.uk";
renew 1 2016/01/25 21:27:07;
rebind 2 2016/01/26 06:54:04;
expire 2 2016/01/26 09:54:04;
}
Associated messages file on server maui
Jan 25 09:54:04 maui dhcpd: DHCPDISCOVER from 78:24:af:3a:7e:3a via eth0
Jan 25 09:54:05 maui dhcpd: DHCPOFFER on 148.197.29.130 to 78:24:af:3a:7e:3a
(paxos) via eth0
Jan 25 09:54:05 maui named[29523]: client 148.197.29.5#39074: updating zone
'jaa.org.uk/IN': adding an RR at 'paxos.jaa.org.uk' A
Jan 25 09:54:05 maui named[29523]: client 148.197.29.5#39074: updating zone
'jaa.org.uk/IN': adding an RR at 'paxos.jaa.org.uk' TXT
Jan 25 09:54:05 maui dhcpd: Added new forward map from paxos.jaa.org.uk to
148.197.29.130
Jan 25 09:54:05 maui named[29523]: client 148.197.29.5#55776: updating zone
'29.197.148.in-addr.arpa/IN': deleting rrset at '130.29.197.148.in-addr.arpa'
PTR
Jan 25 09:54:05 maui named[29523]: client 148.197.29.5#55776: updating zone
'29.197.148.in-addr.arpa/IN': adding an RR at '130.29.197.148.in-addr.arpa' PTR
Jan 25 09:54:05 maui dhcpd: added reverse map from 130.29.197.148.in-addr.arpa.
to paxos.jaa.org.uk
Jan 25 09:54:05 maui dhcpd: DHCPREQUEST for 148.197.29.130 (148.197.29.5) from
78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 09:54:05 maui dhcpd: DHCPACK on 148.197.29.130 to 78:24:af:3a:7e:3a
(paxos) via eth0
Reboot here
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf
/var/run/dhclient-eno1.pid -lf \
/var/lib/NetworkManager/dhclient-81ded380-936a-405c-83f2-bfd5b980f69d-eno1.lease
\
-cf /var/lib/NetworkManager/dhclient-eno1.conf eno1
[root@paxos:~]$ ls -l
/var/lib/NetworkManager/dhclient-81ded380-936a-405c-83f2-bfd5b980f69d-eno1.lease
-rw-r--r--. 1 root root 524 Jan 25 10:26
/var/lib/NetworkManager/dhclient-81ded380-936a-405c-83f2-bfd5b980f69d-eno1.lease
[root@paxos:~]$ cat
/var/lib/NetworkManager/dhclient-81ded380-936a-405c-83f2-bfd5b980f69d-eno1.lease
default-duid "\000\001\000\001\0368\264\335x$\257:~:";
lease {
interface "eno1";
fixed-address 148.197.29.131;
option subnet-mask 255.255.255.0;
option routers 148.197.29.254;
option dhcp-lease-time 86400;
option dhcp-message-type 5;
option domain-name-servers 148.197.29.5,212.104.130.9;
option dhcp-server-identifier 148.197.29.5;
option broadcast-address 148.197.29.255;
option domain-name "jaa.org.uk";
renew 1 2016/01/25 22:15:10;
rebind 2 2016/01/26 07:26:38;
expire 2 2016/01/26 10:26:38;
}
Associated messages file on maui
Jan 25 10:26:37 maui dhcpd: DHCPDISCOVER from 78:24:af:3a:7e:3a via eth0
Jan 25 10:26:38 maui dhcpd: DHCPOFFER on 148.197.29.131 to 78:24:af:3a:7e:3a
(paxos) via eth0
Jan 25 10:26:38 maui named[29523]: client 148.197.29.5#56622: updating zone
'jaa.org.uk/IN': update unsuccessful: paxos.jaa.org.uk: 'name not in use'
prerequisite not satisfied (YXDOMAIN)
Jan 25 10:26:38 maui named[29523]: client 148.197.29.5#40701: updating zone
'jaa.org.uk/IN': update unsuccessful: paxos.jaa.org.uk/TXT: 'RRset exists
(value dependent)' prerequisite not satisfied (NXRRSET)
Jan 25 10:26:38 maui dhcpd: Forward map from paxos.jaa.org.uk to 148.197.29.131
FAILED: Has an address record but no DHCID, not mine.
Jan 25 10:26:38 maui dhcpd: DHCPREQUEST for 148.197.29.131 (148.197.29.5) from
78:24:af:3a:7e:3a (paxos) via eth0
Jan 25 10:26:38 maui dhcpd: DHC
