I installed mosquitto on my Raspberry Pi.
I installed the MQTT Binding, MQTT Binding (1.x) using PaperUI.
I created an item:
Number mqtt_kitchen_gas "Gas Level [%.1f]" {mqtt="<[mosquitto:Home/Floor1/Kitchen/Gas_Sensor:state:default]"}
I opened a terminal window and sent:
mosquitto_pub -u openhabian --pw xxxx -t "Home/Floor1/Kitchen/Gas_Sensor" -m 10
The value "10" appeared in the Gas Level field.
I could change "10" to any number and that would appear in the field.
All was good with the world.
Then I rebooted and looked for the binding MQTT. It is not listed under Configuration, Bindings. (GPIO, another binding I installed is listed.) Also, if I search the Add-ons for MQTT it shows MQTT Binding (1.x) is installed (can be uninstalled) and I can still change the Gas Level field using the above mosquitto_pub.
Maybe I shouldn't worry about it since it works but maybe I have something wrong with my installation and it will come back to bite me.
Any opinions?
I am not completely sure (about 75% :D), but i think that the MQTT 1.x Binding simply doesn't provide any configuration that could be done in paper ui.
That could be the reason why it isn't displayed in the config section.
Since it appears in the addons section and works, everything should be fine.
I am using this binding too and it works properly for ages.
Of course i checked my configuration area in paper ui and it isn't shown there for me too.
Anyways its always fine to check the logs regularly for problems.
If there are none, installation is fine.
Related
I'm working with the following:
Docker for Windows v20.10.11
Docker running in Windows container mode
mcr.microsoft.com/windows:1903 base image
Proprietary application installed on top of this base image
Each year we create a Docker image with the latest version of our company's software. However this year's version behaves differently. Host machine installation runs fine. Containerized installation fails to run in certain situations. I can start the application as a simple EXE, for example using the Docker run command. The app will start and show up in "tasklist". However I can't start the app via the COM API, which is a critical requirement. The problem appears to be COM related. Normally we can create COM objects for our software just like for any other application. For example, IE returns a COM object just fine:
Creating these objects for our application works outside containers. However inside the container, our latest installation gives this error:
Access permissions appear to be ok. I tried a couple tests to prove this. First I can install other software like MS Word into a container and create COM objects for that:
Second I tried retrieving + modifying the application's DACL in PowerShell.
Changing access masks or trustees can cause an Access Denied error:
This also appears to confirm the access permissions were Ok by default.
Next I made sure COM is aware of the application. This appears to be fine. I get the same result on host machine and container when running this PS script:
gci HKLM:\Software\Classes -ea 0| ? {$.PSChildName -match '^\w+.\w+$' -and
(gp "$($.PSPath)\CLSID" -ea 0)} | ft PSChildName
The application shows up just like any other. The details show up fine when querying by AppID. LocalServer32 points to the correct EXE:
Some other things I tried:
Querying registry keys. There are 7 keys created when installing our software. These appear identical on host machine install and container install.
Even though permissions appear fine, I still tried logging into the container as alternate users. For example "nt authority\system" is another virtual admin user. I also changed the password of the "builtin\administrator" user to enable logging in with that one. Lastly tried creating new users entirely and adding them to the Administrators user group. All these attempts had the same errors as "builtin\containeradministrator" (default user).
A minor check was ensuring CMD.exe / Powershell is running as x64:
Re-registering the DLLs associated with the installation using regsvr32.
Starting from different base images. https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images. The full Win Server base image behaves exactly the same way regarding errors. The smaller Win Server Core base image is even more problematic, as I can't even start the app's EXE manually using that base. Lastly I tried other tags of the full Windows base image such as 20H2 and 2004. Same result from those. Multiarch or x64 makes no difference.
Included the "Ogawa hack" which was historically needed to make MS Office apps function correctly with COM: https://stackoverflow.com/a/1680214/7991646. It could be necessary for other COM apps too, but didn't help with my specific installation.
Is there anything else I can do to diagnose or solve this COM issue?
There are several things to consider:
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
The When CoCreateInstance returns 0x80080005 (CO_E_SERVER_EXEC_FAILURE) page describes possible reasons.
If many COM+ applications run under different user accounts that are specified in the This User property, the computer cannot allocate memory to create a new desktop heap for the new user. Therefore, the process cannot start. See Error when you start many COM+ applications: Error code 80080005 -- server execution failed for more information.
Finally, you may find a similar thread here helpful, see Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
does anyone know if this is possible?
All I can find in docs is reference to enabling docker experimental features, but not the kubernetes experimental features.
I tried this, but still get error.
k alpha debug -it exchange-pricing-865d579659-s8x6d --image=busybox --target=exchange-pricing-865d579659-s8x6d
error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").
Thanks
I had the same intent (as have others in this feature request). After several hours of trial and error, I finally found out a way to do so.
Steps:
Depending on which file you're trying to edit, you may need to fully shut down Docker Desktop, and restart WSL. (right-click tray-icon and press "Quit Docker Desktop", then run wsl --shutdown, then run wsl)
Open the [...]/kubeadm/manifests folder, in the Docker filesystem.
On Windows, navigate Windows Explorer to:
For Docker Desktop 4.2.0: \\wsl$\docker-desktop-data\version-pack-data\community\kubeadm\manifests
For Docker Desktop 4.11.0: \\wsl$\docker-desktop-data\data\kubeadm\manifests
Open the kube-controller-manager.yaml, kube-apiserver.yaml, and kube-scheduler.yaml files, adding the line below:
spec:
containers:
- command:
[...]
- --feature-gates=EphemeralContainers=true <-- add this line
Start Docker Desktop again.
It looks so easy when its already figured out, huh? Well trust me, it was a pain to find out.
Some of the slowdowns I hit:
It took me quite a while to even find those manifest files. (eventually found it using grepWin, searching through the whole \\wsl$\docker-desktop-data folder for any matches of a line I grabbed from the kube-apiserver-docker-desktop pod's config, which I viewed using Lens)
Once I found it, I got confused by this documentation. When I read FEATURE STATE: Kubernetes v1.22 [alpha], I thought that meant you needed version 1.22 or higher of Kubernetes for the feature to be available. This caused a huge wild goose chase where I tried to change the version of Kubernetes that was being launched in Docker Desktop, which Docker Desktop didn't seem to like. (in retrospect, the issue may have just been the minor one in point 3 below...)
When I first made changes to the manifest files, I was using Notepad++. And despite my liking Notepad++, it's apparently not quite as smart as vscode in the following regard: it does not automatically detect the indentation type for yaml files. Thus, when I pressed tab to create an indent, so I could add the new flag to the argument list, it added it as a tab character rather than spaces. This caused Kubernetes to fail reading of the file. That might not be so bad if Kubernetes gave a sane error message for that, but instead it merely gave the message unexpected EOF. And I didn't even see that error message at first because it was not being propagated to the kube-controller-manager-docker-desktop pod (which was the only relevant one that wasn't immediately erroring/closing). Anyway, I didn't realize this was the problem at the time, so...
I decided to try bypassing the manifest-files and applying my modification to the etcd data-store directly. In retrospect, this was not a good idea, because the etcd data-store is pretty complex, the tooling is substandard, and the documentation is substandard. I spent a ton of time just trying to figure out how to send commands to read and write data to it (eventually managed to do so by calling etcdctl within the etcd-docker-desktop pod). I spent further time still writing up a NodeJS script capable of reading all the data as JSON, storing it in a dump file, and being able to write changes to entries back despite there being 3+ levels of quoting involved (I eventually was able to use stdin to pass the value rather than as part of the command string, to avoid quotation-mark-inception). After all the work on etcd reading/writing above, I found it didn't work anyway because Kubernetes invariably "breaks" if anyone else writes to its etcd data-store. (even if you write the exact same value that had been there before -- as verified by comparing the dumps before and after)
After all of the above, I decided to have one last go with just adding the flags to mentioned manifest files. Was still getting the startup failure/error, but at the very end, I decided I wanted to see exactly what about my changes was causing Kubernetes to reject them. So I tried commenting out my added line; the error remained. I thought maybe it was a checksum-based rejection then. But then I thought, maybe the YAML parser that Kubernetes is using is just outdated and is finicky about what comments it is able to recognize. So I tried moving the comment around to different places, and was puzzled when the manifest was being accepted just by moving the comment to the root level. I moved it back to various locations, with it working and not working, until I thought to try making the line "half-indented" since it's "in-between" the working and non-working versions. That's when I noticed the line had a tab as its indent. And then it hit me; are the other lines also using tabs? I checked, and nope, they were using spaces. And that's when I realized I had wasted the last few hours on something I coulda just fixed with a simple indent change.
The moral of the story for some is that YAML is a bad configuration format, because it makes it easy to make trivial errors like this. But I actually place the blame more on whatever parser Kubernetes is using for the YAML files; it is unacceptable that a YAML parser would encounter an indentation mismatch and give a message so generic as unexpected EOF. I don't know what the identity of that YAML parser is, but I'm tired enough of the subject that I'm not even going to look into it right now. If one of you finds it, please make an issue report for it -- perhaps including this story as a real-world example of the pain that ambiguous error messages can cause.
Since Ephemeral Containers is still an alpha feature, it is disabled by default.
As you can read here, for this to work, it requires the EphemeralContainers feature gate to be enabled, and Kubernetes client and server version v1.16 or later.
As to the 2nd requirement I assume both your Kuberntes server and client versions are v1.16 or later but it looks like, for the time being, the 1st requirement cannot be met on Docker Desktop. According to this issue, it currently doesn't support enabling Feature Gates.
However you may still try to ssh to your master node and edit the following files:
/etc/kubernetes/manifests/kube-apiserver.yaml
/etc/kubernetes/manifests/kube-scheduler.yaml
by adding inside the command section:
--feature-gates=EphemeralContainers=true
Then you need to delete those pods so they are recreated with new settings applied. You'll find them by running:
kubectl get pods -n kube-system
I am trying to use this to monitor hdd health:
https://share.zabbix.com/storage-devices/smartmontools/smart-monitoring-with-smartmontools-lld
I have followed the steps for the agent and server (at least that is my understanding) and would like to know how can I check the monitoring status. even though I might only get an alert in the dashboard if something goes wrong, I would like to see the current status, understand if monitoring is working and everything is ok.
I have followed the linux agent installation steps here: https://github.com/v-zhuravlev/zbx-smartctl
I have also imported the template on the zabbix frontend, and associated the template with the server being monitored.
What now? How can I check if this is working? It seems like there is something missing, but I am not sure where or how to check.
UPDATE:
I am using this template (which mentions Zabbix 3.4) even though I am using Zabbix 4. Since the template in Zabbix Share mentioned it was compatible with 3.4+, I assume this is not an issue: https://github.com/v-zhuravlev/zbx-smartctl/blob/master/Template_3.4_HDD_SMARTMONTOOLS_2_WITH_LLD.xml
Now you should go to "Latest data" and select your server as a host.
You will get the list of the discovered items where you will find the items related to the disk health.
Then, try to select an item and build with it a graph for example and put it in a dashboard.
We use SATO CL412e printers to print labels (3x7), with the label coming from a local SSRS report. Until recently, this setup worked without issue. A few months ago we modified the label, and implemented (new implementation) at one site (Site A). Then a few weeks ago, we pushed the change out to another site (Site B) that had previously been using this label (old version). Since we did this, the label at Site B is... weird.
The barcode is quite clearly not right, and all the normal characters are squished together, and perhaps bolded. Theoretically, we have proved that it is not the application (which recently changed as well) or the label report because it works fine at Site A, as well as from a different printer (same model, same drivers, etc.) at Site B.
Yesterday the drivers at Site B were updated to match Site A, which resulted in no change. This morning we found a few settings in the web interface that were different. I have not heard yet, but I seriously doubt it will have an effect.
What am I missing? To date, this exactly configuration works on three printers, and fails on one. I am at a complete loss as to what to check next. What could possibly cause this behavior?
Edit:
It has been discovered that this happens only through RDP. When we use a Citrix connection to the same server, we have no problem. It has been suggested that maybe this is a problem with the Internet Explorer settings. Any basis to this, and what settings?
RDP has a feature which connects your local printers to the remote server. This can mean the printer you get when connected with RDP is different than the printer when you are locally working on that server, or using Citrix. It's possible your local workstation has the same printer defined with different settings.
In your RDP connection dialog, click "Settings" and click the "Local resources" tab. Then clear the "Printers" checkbox to prevent this behavior.
I'm using asterisk and asterisk-gui. But they are not conneciton.
I'm new to asterisk.
I run it on CentOs 6.5 and I'm using Asterisk 1.8.25.0.
I was set sip.conf, extensions.conf.
Calling, speaking and listening is no problem.
And, i was install Asterisk-GUI.
http://localhost:8088/asterisk/static/config/cfgbasic.html
This page is normally operates.
However, Asterisk and Asterisk-GUI is not connected.
My accounts are 108, 109.
But, don't show in Asterisk-GUI.
How to connect Asterisk, Asterisk-GUI?
AsteriskGUI is not supported anymore. User freepbx.org gui.
If you need AsteriskGUI(older unsupported version), you need be guru in javascript debugging. Except js issues, also can be issues with firewall or /etc/asterisk/manager.conf file.