I’m going through and reorganizing all the posts and content I’ve added over the last 15 years. Hopefully by the end, it’ll be a bit more structured for my liking.
FileSystemWatcher – LastAccess Not Working
To have System.IO.FileSystemWatcher LastAccess work, the system must have access logging enabled with the following command.
fsutil behavior set DisableLastAccess 0
After setting this, reboot, and you can successfully use the FileSystemWatcher to monitor LastAccess of files (sorta).
Example Code
FileSystemWatcher lWatcher = new FileSystemWatcher(@"C:\windows\temp", "*.*");
lWatcher.NotifyFilter = NotifyFilters.LastAccess;
lWatcher.EnableRaisingEvents = true;
lWatcher.Changed += new FileSystemEventHandler(HandlerWatcherChanged);
lWatcher.IncludeSubdirectories = true;
}
}
static void HandlerWatcherChanged(object sender, FileSystemEventArgs e)
{
Console.WriteLine("[" + DateTime.Now.ToString() + "] ACCESS " + e.FullPath.ToString());
}
Cisco WAP571 SNMP poll of apRadioNumAssociatedStations returning 0
For some reason on a Cisco WAP571, the SNMP value returned from apRadioNumAssociatedStations is always zero.
This is true on firmware tested WAP571 (pgwap571, 1.1.0.3).
I have a few of these units around that are not updated to the latest firmware and will test that OID.
I can find data in the apAssocTable to create indexes. For now I’ve created a hack to just snmptable the apAssocTable and count return index values to then pass to Cacti to graph.
snmptable -Cl -CB -Ci -OX -Cb -Cc 16 -Cw 64 -v2c -c <community> <host:port> CISCO-WLAN-ACCESS-POINT-MIB::apAssocTable | grep index | wc -l
ISPConfig3 – DNSSEC ERROR: We are low on entropy.
It seems that ISPConfig3 checks for entropy availability to be below 200 and also 400 per the following file, /usr/local/ispconfig/server/bind_plugin.inc.php.
Line 93 and line 210 check for entropy availability.
Line 93, inside function soa_dnssec_create():
if (file_get_contents('/proc/sys/kernel/random/entropy_avail') < 400) {
$app->log('DNSSEC ERROR: We are low on entropy. Not generating new Keys for '.$domain.'. Please consider installing package haveged.', LOGLEVEL_WARN);
echo "DNSSEC ERROR: We are low on entropy. Not generating new Keys for $domain. Please consider installing package haveged.\n";
return false;
}
Line 210, inside function soa_dnssec_update():
if (file_get_contents('/proc/sys/kernel/random/entropy_avail') < 200) {
$app->log('DNSSEC ERROR: We are low on entropy. This could cause server script to fail. Please consider installing package haveged.', LOGLEVEL_ERROR);
echo "DNSSEC ERROR: We are low on entropy. This could cause server script to fail. Please consider installing package haveged.\n";
return false;
}
My problem seems to be entropy_avail is 256.
Researching this, I found this Unix StackExchange article, kernel 5.10.119 caused the values of /proc/sys/kernel/random/entropy_avail and poolsize to be 256 – Unix & Linux Stack Exchange, that describes a recent change in the Linux Kernel 5.10.119.
I am currently on Linux kernel 5.10.127-1 (2022-06-30).
To work-around this, I adjusted the checks to both be 200, instead of one being 200 and the other 400 (on creation of DNSSEC records).
I was able to successfully generate the DNSSEC for my zone and issue /usr/local/ispconfig/server/server.sh without additional error.
This is probably NOT the best way to handle this… but I’m not sure what else to do at this point.
snmptable
snmptable -Cl -CB -Ci -OX -Cb -Cc 16 -Cw 64 -v2c -c <community> <host:port> CISCO-WLAN-ACCESS-POINT-MIB::apAssocTable
On a Cisco WAP571, it produces the following output.
Interface Authenticated Associated RxPackets TxPackets RxBytes TxBytes ListenInterval LastRssi TxDropBytes RxDropBytes TxDropPackets RxDropPackets ClntQoSStatus BwLimitUp BwLimitDown ACLType ACL Policy TsViolateTxPack TsViolateRxPack Uptime index: [8:c5:e1:35:b5:89] wlan1vap2 yes yes 17056 23016 3871353 25017797 10 32 0 0 0 0 Disabled 0 0 None Wrong Type (sho Wrong Type (sho 00:01:03 index: [48:90:2f:cd:9f:35] wlan1vap2 yes yes 75219 433258 14643877 530054579 2 22 0 0 0 0 Disabled 0 0 None Wrong Type (sho Wrong Type (sho 00:02:10 index: [7c:f3:1b:bf:ca:ff] wlan0vap2 yes yes 14351 23055 1897849 28821887 5 15 0 0 0 0 Disabled 0 0 None Wrong Type (sho Wrong Type (sho 00:00:36 index: [8c:83:e1:ce:33:f2] wlan1vap2 yes yes 91 93 15906 37253 5 39 0 0 0 0 Disabled 0 0 None Wrong Type (sho Wrong Type (sho 00:00:19 index: [b8:d7:af:f:47:4c] wlan1vap2 yes yes 9948 8279 1935919 3804742 10 30 0 0 0 0 Disabled 0 0 None Wrong Type (sho Wrong Type (sho 00:06:30
ChromeOS Flex Download
Direct download of the ChromeOS Flex bin files are available at Chromium Dash.
The ChromeOS Flex recovery does not work on Linux, but you can use the following to workaround that.
Here are the instructions for the Linux script:
- On the Linux computer, download the Recovery Tool.
- Change the script permissions to allow execution with the following command:
sudo chmod 755 linux_recovery.sh - Run the script with root privileges with the following command:
sudo bash linux_recovery.sh --config https://dl.google.com/dl/edgedl/chromeos/recovery/cloudready_recovery.conf - Follow the on-screen instructions to create recovery media.
- To continue to recover your Chromebook, follow the steps above.
--config https://dl.google.com/dl/edgedl/chromeos/recovery/cloudready_recovery.conf
Here are a couple photos of me running this on a Lenovo ThinkCentre M70z 16GB RAM i5-10400U 6 core with 512GB SSD.
