I have tried Modifying the Registry Key SOFTWARE\Microsoft\Windows NT\CurrentVersion\Ports\COM#: for my specific COM Port in use and it works GREAT! BUT. . . .
It will not set the Flow Control!! For example - if I change Flow Control to Hardware the registry entry changes from 9600,n,8,1 to 9600,n,8,1,p - noting that ,p is what's changed in the registry. . . If I change it manually from Hardware to Xon / Xoff, the registry's ,p changes to ,x and if I set it to None the final item is removed.
Conversely, if I change this registry manually from 9600,n,8,1 to 9600,n,8,1,p it will NOT change the Flow Control. It successfully changes everything else, but the Flow Control fails to update. . .
How do I change Flow Control (permanently) via Batch, CMD, PowerShell, VBScript, etc?
I just found it. The Registry to change is not found in the same place (although I would recommend setting the Registry entry mentioned in the Question to match what Windows would expect - meaning adding the ,p to the end of this value.)
The Registry Key is HKLM\SYSTEM\CurrentControlSet\Control\Serial Print\COM#\ and the Value is FlowControlType, Type is REG_DWORD and Data is 1 for Hardware choice.
Full disclosure:
FlowControlType set to 2 = None
FlowControlType set to 0 = Xon / Xoff
Modifying this Registry via CMD, the Device Manager Port settings for selected COM# port shows the change.
If there are any downsides to modifying this vs another method, please provide another answer. I'll wait a couple days before accepting this answer in case there's a better (Native) way without having to build an executable.
Related
Hi I'm spinning out Pantheon's Localdev for testing and I'm getting this warning message on the logs
You have a lot of keys!
Any ideas what is causing this warning?
I think this is related to lando. This thread on Github suggests:
To disable the warning you can run lando config you will see a maxKeyWarning setting. This value can be overridden in a lando global config file, i.e. set the value that matches your number of used keys..
As documented in the SSH keys config page, the keys key is meant to be used in combination with a user-space Lando override file. This file is .gitignored and is meant to provide user-specific overrides, eg you would not put ALL the keys of ALL the users here, just yours.
According to the subject, I only found out the right .c file to set persist flag in "adb shell reboot"( system/core/reboot/reboot.c), but I can't find it in "adb reboot". What the difference between the two reboot commands??
The flags governing the initial behavior of adbd are "ro" and therefore cannot be altered on a running system, but rather only by re-generating the boot image.
The relevant section of the source code for should_drop_privileges() has an explanatory comment.
// The properties that affect `adb root` and `adb unroot` are ro.secure and
// ro.debuggable. In this context the names don't make the expected behavior
// particularly obvious.
//
// ro.debuggable:
// Allowed to become root, but not necessarily the default. Set to 1 on
// eng and userdebug builds.
//
// ro.secure:
// Drop privileges by default. Set to 1 on userdebug and user builds.
Typically your goal would be accomplished by using an eng rather than userdebug build or else by customizing these settings to different values than the default for your chosen build flavor.
eng
defaults to root
adbd runs by default
does not require adb keys
ro.debuggable=1, ro.secure=0
userdebug
allows adb-root
adbd runs by default
does not require adb keys
ro.debuggable=1, ro.secure=1
user
does not allow adb-root
adbd off by default until enabled in Settings
requires adb keys
ro.debuggable=0, ro.secure=1
Realistically it may be easiest to just execute the adb root each time you need to use it. In a script you might follow it by a sleep of a second or two or better yet poll for the device to start responding again. Ultimately try to work the things you need to do as root into the original configuration of the built system such that you can end up with a user flavor build (adb root unsupported) in production, unless your goal is to make a device for experimentors rather than turnkey users.
In IIS 7.5, I am trying to update the request restrictions for the handler mappings. I know you can use appcmd or ps and edit the verbs or access, but I want to be able to run a command that will "Invoke handler only if request is mapped to: FILE".
I found this article in technet, which basically will allow me to edit everything except the tab that I need to change.
https://technet.microsoft.com/en-us/library/cc730969(v=ws.10).aspx
For example
appcmd set config /section:handlers /[name=' ImageCopyrightHandler '].verb:GET,HEAD
I've tried pretty much every command I can come up with but none of them seem to work.
This is what I am trying to edit for each handler mapping.
I'd hate to have to do each one manually, since it has to be done on 3 servers are there are 35 isapi module handers in each one. Any ideas?
The attribute you're looking for is resourceType with a value of File
You sir are awesome.
For anyone interested here is the full string that I'm using for each module.
appcmd set config /section:handlers /[name='PageHandlerFactory-ISAPI-4.0_32bit'].resourceType:File
I have read the documentation concerning falling back to environment variables at https://github.com/typesafehub/config/blob/master/HOCON.md#substitution-fallback-to-environment-variables. My understanding was that it would pickup any envars. So for instance, if from the shell I was able to do echo $HOSTNAME and see a non-empty response then HOCON should do that as well.
In my application.conf I have a line
akka.remote.netty.tcp.hostname = ${HOSTNAME}
However, my app is not happy with this and fails to start with.
/conf/application.conf: 9: Could not resolve substitution to a value: ${HOSTNAME}
Is this a user issue? A shell issue? I am able to login as the user and echo $HOSTNAME
Tagging this scala and akka since that userbase probably has the most exposure to HOCON
The reason for HOCON not picking up the envar is that my app runs as a linux service (Centos 6.5) which clears away most environment variables.
See https://unix.stackexchange.com/questions/44370/how-to-make-unix-service-see-environment-variables for a relevant description of the issue
this is a shot in the dark, but are you using an older version of typesafe-config? maybe its a newer-ish feature? the feature seems to be advertised as you describe, but if you are pulling in typesafe-config as a transient dependency (say from akka), maybe you are getting an older version.
what happens if you remove the substitution in your .conf file (so parsing is successful) and then print out the contents of ConfigFactory.systemEnvironment()? for reference: http://typesafehub.github.io/config/latest/api/com/typesafe/config/ConfigFactory.html#systemEnvironment--
HOSTNAME isn't an environment variable. It's a bash internal variable. See https://superuser.com/questions/132489/hostname-environment-variable-on-linux for more details.
I am trying to start a google compute engine (GCE) instance with a pre-configured FQDN. We are intending to run an application that is licensed based on the contents of /etc/hosts.
I am starting the instances using the Google Cloud SDK utility - gcloud.
I have tried setting the "hostname" key using the metadata option like so:
gcloud compute instances create mynode (standard opts) --metadata hostname=mynode.example.com
Whenever I log into the developer console, under computer, instances, I can see hostname under "Custom metadata". This appears to be a new, custome key - it has no impact on what:
http://metadata.google.internal/computeMetadata/v1/instance/hostname
returns.
I have also tried setting "instance/hostname" like the below, which causes a parsing error when using gcloud.
--metadata instance/hostname=mynode.example.com
I have successfully used the startup scripts functionality of the metadata server to run a startup script that parses the new, internal IP address of the newly created instance, updated /etc/hosts. This appears to work but doesn't feel "like the google way".
Can I configure the FQDN (specifically, a domain name, as the instance name is always the hostname) of an instance, during instance creation, using the metaserver functionality?
try this:
Go to your GCE >> VM instances panel.
stop your gce instance.
clic on the instance name.
Edit your instance, adding this values on Custom metadata fields:
Key field: hostname / Value field: your.server.hostname
Key field: startup-script / Value field: sudo -s hostnamectl set-hostname your.server.hostname
setup-example-image.png
Finally, start your instance and test with a hostnamectl command.
regards!
According to this article 'hostname' is part of the default metadata entries that provide information about your instance and it is NOT possible to manually edit any of the default metadata pairs. You can also take a look at this video from the Google Team. Within the first few minutes it is mentioned that you cannot modify default metadata pairs. As such, it does not seem like you can specify the hostname upon instance creation other than through the use of a start-up script like you've done already. It is also worth mentioning that the hostname you've specified will get deleted and auto-synced by the metadata server upon reboot unless you're using a start-up script or something that would modify it every time.
If what you're currently doing works for what you're trying to accomplish, it might be the only workaround to your scenario.
Here is a patch for /usr/share/google/set-hostname to set FQDN to GCE instance.
https://gist.github.com/yuki-takeichi/3080521322f0f1d159ea6a343e2323e6
Before you use this patch, you must set your desired FQDN in your instance's metadata by specifying hostname key.
Hostname is set each time instance's IP address is renewed by dhclient. set-hostname is just a hook script which dhclient executes and serves new IP address and internal hostame to, and modifies /etc/hosts. This patch changes the source of hostname by querying instance's metadata from metadata server.
The original set-hostname script is here:
https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google_config/bin/set_hostname.
Use this patch at your own risk.
When creating a VM, you can specify a custom FQDN hostname as an optional parameter. This feature is currently in Beta.
$ gcloud beta compute instances create INSTANCE_NAME --hostname example.hostname
This should work across OSes, and eliminate the need for workaround scripts.
More info in the docs.
-- Sirui (Product Manager, Google Compute Engine)
I've looked throughout this site to find answered questions and found a few things that work but with a couple solutions combined. This thread seems the place to answer.
1) echo example.com > /etc/hostname
2) add -- 127.0.1.1 example.com in /etc/hosts
3) add -- hostnamectl set-hostname
example.com -- command to /etc/rc.local script
4) uncomment /etc/dhcp/dhclient.conf line:
supersede domain-name "example.com";
5) profit.... Seems to stick after each reboot
(Note example.com is your domain name: fqdndomain.com - yourfqdndomain.org)
Also note this is for Ubuntu or Debian. Other Unix May slightly vary. I've tested this on Ubuntu 16.04
Always on the wording NOT possible to manually edit any of the default metadata pairs, how about the instant level default metadata "/scheduling"? we could set them manually as mentioned in this article