Stage 5, day 13:
I spend most of my day doing tech support. I'm kinda the sysadmin at home and my recent server merging had some undesirable side effects.
1. The smart door bell doesn't connect anymore to the network. That might be totally unrelated to the merging (but I did change the position of the router, so maybe the signal strength did drop too low for the ring to continue connect). So first thing that I did is to optimize the router location by placing it on top of the server box instead of behind it.
Nah, that didn't do anything good. Second option, is to press the setup button on the door bell to reinitialize it. To do that, I need to find the security screwdriver to open the bell box. I have only used it once when I did install the thing and I simply did not find it. I guess it is safe to declare that it is lost.
They sell spare ones on Amazon at $7.95 but with S&H, the total amount goes up to $35. It's pretty expensive but I feel that I have no other options. So I did order one and put this task on hold until I receive the screwdriver.
Scanner doesn't work anymore. I had this nice setup where I created a Samba drive on my NAS server so you can scan a document and access the scanned result file from anywhere in the house through the NAS. When I merged the servers, the Samba share IP address did change. I thought that by simply changing the IP address setting in the printer would fix the problem. It didn't. I have no idea what is making this setup that did perfectly work for years suddenly stop working when moving the server. I did struggle for pretty much the whole afternoon on that problem. There is nothing that I haven't tried including upgrading the printer firmware. Nothing did fix that and the only info that the printer was giving is that it was unable to reach the SMB share.
I did pause one moment, and I did question why I did use Samba in the first place. A Samba share can be useful in a heterogeneous environment that includes Windows machines. Since I'm anti-Microsoft and anti Bill Gates, there is absolutely zero Windows machine at my place and the printer also support FTP to transfer scans.
Update: Now I remember. It is simply a legacy leftover. When I had my old Linksys NAS (and still had few Windows machines around), it was supporting SMB shares and this is something that my printer could accept and it did work out of the box on the first attempt. I didn't thought about this choice any further despite that the Linksys box was possibly also supporting FTP (I make an association with FTP as being archaic and insecure. Telnet is another protocol in that mental category). When I did replace the Linksys box with a Linux box, I didn't question the original choice. I just did bring Samba support to the Linux box to keep the printer continue working as-is.
I did remove the Samba software and replace it with a FTP server. It didn't work out of the box. I had minor issues with PAM authentication and the info contained in the /etc/passwd file. but this operations has again demonstrated that MS software is of bad quality, bloated and slow. To be fair, Samba does probably offer much more functionality than just what FTP provides but from my point of view and my needs they are essentially equivalent. Samba software was 150MB big and it has been replaced by a 0.5 MB software that does the exact same thing!
Scanner problem fixed.
Those problems did drag me away big time. I hope this time, I am 100% done with that damn migration. That is why I avoid those type of moves. When you initiate them, it can become the equivalent of opening a can of worms.
Hopefully, and I'm happy about that, I also had enough time to fix an illusive SEGV bug still inside my trading library. The problem occurs when I reset my router or if I pull off a network cable somewhere. Part of the difficulty of finding the problem is that the generated core dump has become so big since the program now uses few GB of RAM that the core is truncated. Since the stacks are located at the end of the process virtual memory, this crucial info is missing making it pretty much impossible to know what the program was doing.
I did change /proc/sys/kernel/core_pattern to request the core to be dumped somewhere where the disk space is sufficient to avoid truncation. I got my core. At first, it wasn't clear what the problem was but I did finally figure it out and as a result, my code is now fixed in that regard.
I spend most of my day doing tech support. I'm kinda the sysadmin at home and my recent server merging had some undesirable side effects.
1. The smart door bell doesn't connect anymore to the network. That might be totally unrelated to the merging (but I did change the position of the router, so maybe the signal strength did drop too low for the ring to continue connect). So first thing that I did is to optimize the router location by placing it on top of the server box instead of behind it.
Nah, that didn't do anything good. Second option, is to press the setup button on the door bell to reinitialize it. To do that, I need to find the security screwdriver to open the bell box. I have only used it once when I did install the thing and I simply did not find it. I guess it is safe to declare that it is lost.
They sell spare ones on Amazon at $7.95 but with S&H, the total amount goes up to $35. It's pretty expensive but I feel that I have no other options. So I did order one and put this task on hold until I receive the screwdriver.
Scanner doesn't work anymore. I had this nice setup where I created a Samba drive on my NAS server so you can scan a document and access the scanned result file from anywhere in the house through the NAS. When I merged the servers, the Samba share IP address did change. I thought that by simply changing the IP address setting in the printer would fix the problem. It didn't. I have no idea what is making this setup that did perfectly work for years suddenly stop working when moving the server. I did struggle for pretty much the whole afternoon on that problem. There is nothing that I haven't tried including upgrading the printer firmware. Nothing did fix that and the only info that the printer was giving is that it was unable to reach the SMB share.
I did pause one moment, and I did question why I did use Samba in the first place. A Samba share can be useful in a heterogeneous environment that includes Windows machines. Since I'm anti-Microsoft and anti Bill Gates, there is absolutely zero Windows machine at my place and the printer also support FTP to transfer scans.
Update: Now I remember. It is simply a legacy leftover. When I had my old Linksys NAS (and still had few Windows machines around), it was supporting SMB shares and this is something that my printer could accept and it did work out of the box on the first attempt. I didn't thought about this choice any further despite that the Linksys box was possibly also supporting FTP (I make an association with FTP as being archaic and insecure. Telnet is another protocol in that mental category). When I did replace the Linksys box with a Linux box, I didn't question the original choice. I just did bring Samba support to the Linux box to keep the printer continue working as-is.
I did remove the Samba software and replace it with a FTP server. It didn't work out of the box. I had minor issues with PAM authentication and the info contained in the /etc/passwd file. but this operations has again demonstrated that MS software is of bad quality, bloated and slow. To be fair, Samba does probably offer much more functionality than just what FTP provides but from my point of view and my needs they are essentially equivalent. Samba software was 150MB big and it has been replaced by a 0.5 MB software that does the exact same thing!
Scanner problem fixed.
Those problems did drag me away big time. I hope this time, I am 100% done with that damn migration. That is why I avoid those type of moves. When you initiate them, it can become the equivalent of opening a can of worms.
Hopefully, and I'm happy about that, I also had enough time to fix an illusive SEGV bug still inside my trading library. The problem occurs when I reset my router or if I pull off a network cable somewhere. Part of the difficulty of finding the problem is that the generated core dump has become so big since the program now uses few GB of RAM that the core is truncated. Since the stacks are located at the end of the process virtual memory, this crucial info is missing making it pretty much impossible to know what the program was doing.
I did change /proc/sys/kernel/core_pattern to request the core to be dumped somewhere where the disk space is sufficient to avoid truncation. I got my core. At first, it wasn't clear what the problem was but I did finally figure it out and as a result, my code is now fixed in that regard.
