Fetch device logs using command line - iphone

I'm working on a project that uses Xcode developer and command line tools, but does not use the Xcode GUI. The procedures omit the GUI for procedural reasons due to the contract, so we can't use it.
We can build from the command line using xcodebuild, perform intermediate steps like codesign and lipo, and install and APP or IPA using fruitstrap or ideviceinstaller.
The program creates detailed logs, and the logs are used to attest to proper execution. Are there any tools to fetch the logs from the device once the program completes its task? (We've given up on Apple-only tools, so third party tools are OK).
Jeff

Related

Porting a pywinauto script from Windows to X11/Xlib

In my organization, I have been using pywinauto to automate some UI procedures that could not be done using the sole command line interface.
In an effort to move away from windows, I am evaluating the effort to port the UI automation script to a Linux environment (our tool has a Linux version, including a similar GUI).
I have had a look at the python-xlib project. But I have the feeling that it is more a framework to develop native X11 applications rather than perform tests on an existing application (I could not find anything like find_window etc...).
Do you have any advice for an X11 framework to automate UI procedures?
Based on several inputs, I finally came up with the following suggestions:
use pywinauto which has some beta level of Linux support (this support is based on pyatspi2).
use directly pyatspi2 to interact with the widgets if they are exposed. To browse through the exposed widgets of the application you want to automate, you can use accerciser.
finally, many framework exist to use only click + keys + mouse locations and are based on image comparison. There are many around, I have not yet tested any of them.
Finally, since my script is meant to run in a docker environment in CI, I installed Xvfb to run the automation in headless mode, without graphics HW.

Unable to install gcloud SDK

When I try to install google cloud SDK, I was getting the following error:
ERROR:
(gcloud.components.update) Failed to fetch component listing from
server. Check your network settings and try again. This will install
all the core command line tools necessary for working with the Google
Cloud Platform. Failed to install.
After reinstalling python (v3.7.0), I added the path and also added CLOUDSDK_PYTHON environment variable to make sure. Now when I attempt the installation, the installation simply hangs:
If I attempt the installation trough terminal by executing install.bat, it also gets stuck after requesting to send diagnostics to google:
Welcome to the Google Cloud SDK!
Active code page: 65001
To help improve the quality of this product, we collect anonymized usage data
and anonymized stacktraces when crashes are encountered; additional information
is available at <https://cloud.google.com/sdk/usage-statistics>. This data is
handled in accordance with our privacy policy
<https://policies.google.com/privacy>. You may choose to opt in this
collection now (by choosing 'Y' at the below prompt), or at any time in the
future by running the following command:
gcloud config set disable_usage_reporting false
Do you want to help improve the Google Cloud SDK (y/N)? n
Nothing gets printed after that.
it seems that the "(gcloud.components.update) Failed to fetch component listing from server" error might be caused by some proxies or antivirus in your environment, I'd recommend you to try a clean installation in a vm or using another network.
Also, I was able to find soem similar errors for this on issue tracker and the team gave a soltion at comment10, also, as you can see on the issue tracker, sometimes this behavior is because the Python SDK is installed on default "Program Files" location, you could give it a try by changing the location of the python SDK

gcloud SDK: difference between command line interface and tools?

After installing Google Cloud SDK, when I ran gcloud components list, I could see a component name called "BigQuery Command Line Tool" and "Cloud DNS Admin Command Line Interface"
Is there a distinction in the nature of command line tools vs interfaces?
Things labeled as "Command Line Tool" typically refer to standalone tools like the bq tool or the gsutil tool. Things labeled as "Command Line Interface" are functionality that get exposed through the unified gcloud tool.
Most of the time, the same functionality is available from gcloud SDK and the GUI interfaces, as they are frontends to the same APIs. Sometimes there are differences, though. There are operations which can only be performed or are only available in one of them, because the APIs are not exposed the same way in both.
The main difference is that the GUI tools are designed only for human usage, while the command line tools can be used programmatically too, due to the way they expose the APIs to the clients.

Prevent user from changing ClickOnce application files after installation

I'm developing a WPF application that I deploy with ClickOnce to a network share on the intranet from which clients can install it.
I need to make sure that the user can't modify any of the application files (especially DLLs and the main executable) on their machine. That is, if any of the application files have changed, the application should refuse to run. I was under the impression that, when using ClickOnce, this was available out of the box and that the application would refuse to start if the file hashes didn't match the manifest.
However, I tried to manually replace the executable or a DLL with a slightly different version after installation and the application still ran fine (executing the modified code).
Does ClickOnce provide what I'm looking for?
How can I enable the functionality?
I'm using a level 2 StartSSL code-signing certificate to sign the application manifest if this matters.
P.S.: just to be sure: I'm talking about the installed application files, not the installation files.
You can sign AND strong name each one of DLLs to prevent tampering but then, doing so has its own pain points when it comes to upgrades and distribution in general. Note that even doing so, doesn't entirely prevent someone from injecting code into your running process. It's a sticky subject.
I recommend going thru this question which already discusses these points in detail. Does code-signing without strong-naming leave your app open to abuse?
I think it will be a fairly manual process.
Doesn't look like the VS2013 deployment tools handle code obfuscation but they do support signing and app permissions. Start with that, then you might have to get the generated manifest as a starting point to build your own with obfuscated assemblies.
MS docs break it into 3 steps: 1. obfuscate, 2. build manifest, 3. manually publish
Here is what MS docs say...
Securing ClickOnce Applications
Deploying Obfuscated Assemblies
You might want to obfuscate your application by using Dotfuscator to prevent others from reverse engineering the code. However, assembly obfuscation is not integrated into the Visual Studio IDE or the ClickOnce deployment process. Therefore, you will have to perform the obfuscation outside of the deployment process, perhaps using a post-build step. After you build the project, you would perform the following steps manually, outside of Visual Studio:
Perform the obfuscation by using Dotfuscator.
Use Mage.exe or MageUI.exe to generate the ClickOnce manifests and sign them. For more information, see Mage.exe (Manifest Generation and Editing Tool) and MageUI.exe (Manifest Generation and Editing Tool, Graphical Client).
Manually publish (copy) the files to your deployment source location (Web server, UNC share, or CD-ROM).

ClickOnce check for update without executing app

I work in a service organization where users of our internal tools are often disconnected. It is often the case that service engineers on service assignments are "stranded" with an outdated version of some internal tool.
These tools are deployed using ClickOnce publish VS2010 .NET4 . If the users run all their apps while still connected to corporate network, they would get a notification that a new version was available. As the number of various tools increase, the chance increases that some app is not updated.
Is it possible to automate this process, by a batch file or something?
So that the engineers just need to run one file when connected to corporate nw to get all the newest versions of their installed tools?
Added:
An easier way of saying it would be to have "something like Windows update" operating on corporate net, but for internal ClickOnce apps.
Very interesting question. I can't think of a quick way to do this, but it's definitely possible.
I would create another ClickOnce app whose job is to update the other ClickOnce apps. This app needs the url of each app's .application file. If all engineers are supposed to have all apps, that's easy. If not, maybe you could look through their start menu and find all the ClickOnce Application Reference files. Those files contain the url.
Next, just launch the url and pass a query string argument...
http://server/MyApp/MyApp.application?UpdateOnly=true
In the startup of your applications, you can check the query string argument and shut down the app if it's run with UpdateOnly=true.
One side note. If you set the minimum required version of each of your apps to the latest version, users won't get prompted with the new version dialog. Seems like you'd want to do that or the user would still have to pay attention and do a lot of clicking.