Again sent earlier. Thanks for the intervening comments about
vulnerabiliteis and versions.
A lot of issues and suggestions have been made and raised. My brief
response is that yes, according to nmap and my intention I had port 23,
for ssh (I moved it) and port 5900 open and the rpc port, I think. I'm
going by memory.
Theoretically the only pinhole in the ISP router firewall was port 23.
To use port 5900, you had to use an ssh tunnel.
My web server is on another machine. Since I only use it for
development, I don't leave it up.
My actual web pages are hosted externally on a vendor's box.
My experience with the upgrade treadmill is that it is a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
The developers for Fedora 13 were no smarter or dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
The issue with an older release is that nifty new things come out and
you can't really use them. But, if you run a VM with a recent version
of the distro, you can use them just fine.
The other issues is that if you are getting vendor support, they can
only reasonably commit to supporting a limited number of versions.
This is AMD hardware from '06.
-Gary
On Fri, Aug 05, 2022 at 06:19:54PM -0700, Rick Moen wrote:
> Quoting Brian E. Lavender (brian(a)brie.com):
>
> > Gary,
> >
> > You were running Fedora 13?
>
> If so, _that_ is likely a big problem. Fedora 13's initial release was
> May 25, 2010, and it was EOLed on June 24, 2011.
>
> Because Fedora. If you don't want to keep moving to newer versions,
> it's about the worst possible distro. (But it's possible Gary meant
> that he did _original_ installation 15 years ago, but has been following
> the recommended upgrade treadmill^W path.
>
> Linus Sphinx wrote:
>
> > https://www.bleepingcomputer.com/news/security/new-linux-malware-brute-forc…
>
> You know, I have a _lot_ of things to be grateful for, and somewhere on
> the list is the glad tidings that I don't need to rely on
> Bleepingcomputer.com for IT information.
>
> Over the past 1.5 months since its discovery, the new botnet used
> over 3,500 unique IPs worldwide to scan and attempt brute-forcing Linux
> SSH servers.
> [...]
> The SSH brute-forcing relies on a list of credentials downloaded from
> the [command and control server]. [...]
>
> *snore*
>
> So, doorknob-twisting for "joe accounts", like user=service
> password=manager and like that.
>
> Guestimate the math, and measure the lengthly setup and teardown times
> for remote connections to an sshd, and you'll find that
> dictionary-attacking an sshd with any reasonable rules set about
> password quality and length is going to take an appreciable fraction of
> the time to the heat death of the universe, to succeed.
>
> I mentioned upthread that a lot of IT device comes from gadget freaks.
> The _other_ common problem is that most security _articles_ are
> copied-pasted press releases from security/antimalware firms.
> So, they're big on shockhorror, and small on conveying understanding.
>
> I've only quick-glanced at this article about enforcing password policy
> via PAM, so won't swear to it being a good one:
> https://www.techrepublic.com/article/controlling-passwords-with-pam/
> Of course, if you're the -only- user, you ought to stick to decent
> passwords without PAM forcing you to. (Also, a user who can su to
> root has the power to overrule PAM. But if you do that, you have only
> yourself to blame for consequences.)
>
> _______________________________________________
> Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
----- End forwarded message -----
Hi Folks,
If I mount a remote share with CIFS, then I can specify the UID and the GID and the UMASK of the files in the paths below the mount point, but these do not reflect anything for the file in its native filesystem. I see gazillions of questions about this, all of which are answered with the tactical answer about UID, GID, and UMASK necessary to let the original poster get on with the limited access they need. There are almost as many postings claiming that CIFS has no other permission/ownership model beyond these global settings.
So, my question is, "Do I have any other mount options?" I want to backup large chunks of my system with "rsnapshot", which is an "rsync" between the stuff to backup and the destination NAS. I need to preserve ownership and permissions, not to mention "case" and "rsync"ing to a CIFS (SaMBa) share is not going to do it. If I "tar" everything, I do preserve file meta data but I pay a penalty in time and space to make copies of relatively static content.
Thanks for the help,
--
Chris.
V:916.799.9461
F:916.974.0428
A: Because we read from top to bottom, left to right.
Q: > Why should I start my reply below the quoted text?
Hi Folks,
I have three NASs: two Buffalo Link Stations, and one ASUStor. It never occurred to me to check for case insensitivity before, but I did and they aren't! This surprises me because case sensitivity is much easier to implement and it does not surprise me because the Windows world is case insensitive.
So, my first question is, "Can I require case sensitivity during the mount command?". I can't find anything about that, but I have seen comments claiming that CIFS mounts are case sensitive by default, but mine clearly aren't.
As an ancillary question, does anybody know if btrfs is case sensitive? I've spent some time looking, but I haven't found any comments I trust. For example, the [ https://en.wikipedia.org/wiki/Btrfs | Wikipedia article ] fails to mention it.
Thanks for the help,
--
Chris.
V:916.799.9461
F:916.974.0428
A: Because we read from top to bottom, left to right.
Q: > Why should I start my reply below the quoted text?
Hi Folks,
O.M.G.! I have spent all afternoon trying to diagnose a DNS problem that presents like corruption but I can't find any trace, beyond the failure that I think is the result. This is a Windows Server problem...
I have a domain name for my NAS -- "\\NAS0.TCLC.org = 10.1.1.80", and all evaluations show me that translation. I can ping it; I can nslookup; I can run the DNS management application. My linux machines can "mount //NAS0.TCLC.ORG/d0 /net/nas0/d0 ..." All work exactly as you'd expect. Then I try to view the share with the Windows File Explorer -- "Windows can't find the DNS name"!! In that case I can use the IP address directly or the alternate domain name, so it is the domain name on the windows machines that is the problem, not the disk access protocol. I also created a second domain name "\\NASX.TCLC.org = 10.1.1.80" and that one work just fine everywhere!
Here I tried the command prompt:
C:\Windows\system32>net use n: \\10.1.1.80\d0
The command completed successfully.
C:\Windows\system32>net use n: /delete
n: was deleted successfully.
C:\Windows\system32>net use n: \\NASX.TCLC.org\d0
The command completed successfully.
C:\Windows\system32>net use n: /delete
n: was deleted successfully.
C:\Windows\system32>net use n: \\NAS0.TCLC.org\d0
System error 64 has occurred.
The specified network name is no longer available.
Of course I have flushed all caches I can find, scavenged resources records, rebooted every element -- Windows DNS server, Windows Server 2012r2, NAS, Client, ... the toaster and the microwave!
So, I have a domain name that shows zero problems in any investigation, until I try to use it for its intended purpose on the windows machines , and I have another one that is nearly identical that has no problems!
Any thoughts?
Thanks for the help,
--
Chris.
V:916.799.9461
F:916.974.0428
Hi Linus,
> Did you say it all worked fine by ip address?
Windows PowerShell:
$ nslookup nasx.tclc.org -- works. Reports 10.1.1.80
$ nslookup nas0.tclc.org -- works. Reports 10.1.1.80
# mount //10.1.1.80/d0 /net/nas0/d0 -- works
# mount //nasx.tclc.org/d0 /net/nas0/d0 -- works
# mount //nas0.tclc.org/d0 /net/nas0/d0 -- works
> dir \\10.1.1.80\d0 -- works
> dir \\nasx.tclc.org\d0 -- works
> dir \\nas0.tclc.org\d0 -- fails
If I change nas0.tclc.org to a different IP, say 10.1.1.81, then dir \\nas0.tclc.org\d0 still fails.
So, any inspection of nas0.tclc.org works everywhere, but any use of nas0.tclc.org fails only on Windows , regardless of the value. I no longer suspect a corruption, since I have purged and reinitialized all known sources and caches. This may be a collision, but that would require some rogue assignment that I haven't found. It may also be a permissions problem, but domain name level permissions is easily checked and I compared this name with nas1.tclc.org, which is not known to have problems. Ultimately, the culprit will have to be the NAS, since this all happened, coincidentally, after a system update. I have review all the settings for the NAS, and I have found nothing.
Thanks for the help,
--
Chris.
V:916.799.9461
F:916.974.0428
A: Because we read from top to bottom, left to right.
Q: > Why should I start my reply below the quoted text?
Hi Linus,
The full story is that I applied an update to this NAS just before this foolishness, so I have every reason to believe that is the culprit, but even knowing this, I am unable to diagnose the problem. Especially given that only one domain name has a problem -- "NAS0.TCLC.org". It is clearly the domain name, not the device; a different domain name (NASX.TCLC.org) works just fine. And the same domain name fails regardless of the IP.
'arp -a', look ok? Should clear at reboot but I've seen stranger things. Is there anything in hosts besides localhost entries? Does the output of the hostname command match the address record? nslookup the address of your machine and see if it's the only entry for it, is this the only interface live?
When I first started to investigate this, I found a bogus DNS entry defining NAS0.TCLC.org as 10.1.1.103 and DHCP told me that this was the address of ASUSTOR-3204T.TCLC.org, which, as you can guess, turned out to be the NAS. I deleted this and cleaned up DNS and DHCP and I have eradicated 10.1.1.103 from the system. I also have no reason why the NAS was asking for an IP. I'm going to chalk it up to some sort of update semantics, because the NAS is configured with a static IP and a DHCP reservation.
All of your proposed diagnostics return exactly what you would expect. arp, nbtstat, nslookup, ping, ... I have even disjoined and rejoined the domain. So far, nothing has had any effect.
From windows PowerShell on any windows machine in the domain:
* dir \\10.1.1.80\d0 -- works
* dir \\nasx.tclc.org\d0 -- works
* dir \\nas0.tclc.org\d0 -- fails
From any Fedora machine, "mount //NAS0.TCLC.org/d0 /net/nas0/d0 ..." works.
So, it is only Windows, and it is only "NAS0.TCLC.org". Any other combination works. This is truly bizarre. I hope it does not simply vanish as quickly as it appeared; I really want to know what is causing this.
Thanks for the help,
--
Chris.
V:916.799.9461
F:916.974.0428
A: Because we read from top to bottom, left to right.
Q: > Why should I start my reply below the quoted text?
I am migrating the server that runs the mailing list to a different
hypervisor. I hope this returns in a couple hours!
Brian
--
Brian Lavender
http://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
It looks like I had something happen to my disk that is attached through
USB to the hypervisor and the VM got mount to read lonely!
Brian
--
Brian Lavender
http://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
