Modified Linux client not working as expected with new functionality #27
Comments
|
From gcastle@google.com on January 08, 2014 14:21:41 Hi Aditya, Take a look at: http://grr.googlecode.com/git/docs/implementation.html particularly the 'testing' and 'debugging client actions' sections. Did you write tests? Running tests is a lot faster than a full build/install cycle for each change. |
|
From aditya.kichu on January 09, 2014 01:19:18 Hello, I have not written tests so far. But I have looked at how its done. Anyway, how does testing help me in this case as I know that the client action and the new flows that I wrote work well in Windows. Theoretically I should see the same behavior in Linux also. Is there something that I am missing? Thanks, Aditya |
|
From aditya.kichu on January 09, 2014 07:23:59 Hello, I checked the flow with parameters that were not involving any new protobuf fields that I had introduced and the flow works fine. This strongly suggests that there is some issue with the new protobuf classes not being included in the client. How do I check this in the client build? Thanks, Aditya |
|
From amoser@google.com on January 09, 2014 07:41:51 Hey Aditya, Here is some troubleshooting hints for installed clients: Find the running client and stop it: grr-build@grr-testing:~$ ps -ef|grep grr root 13923 1 0 2013 ? 00:00:00 /usr/sbin/grrd --config=/usr/lib/grr/grr_2.9.2.0_amd64/grrd.yaml ... grr-build@grr-testing:~$ sudo service grr stop Restart it directly into the debugger: grr-build@grr-testing:~$ sudo /usr/sbin/grrd --config=/usr/lib/grr/grr_2.9.2.0_amd64/grrd.yaml --break_on_start
List known protobufs: (Pdb) from grr.proto import jobs_pb2 (Pdb) from grr.proto import flows_pb2 List known client actions: (Pdb) from grr.client import actions You should be able to tell immediately if your protobuf definitions are missing. If they are, you need to rebuild them: Hope that helps! |
|
From aditya.kichu on January 09, 2014 08:39:00 Hello Andy, I am not able to see either the new protobufs nor the new client actions. I rebuilt the client now and it looks like there is no agent template built in the first place! I was fooled by the build time as it was very close to the time I had copied the source code. That is why, I thought it was building it properly and apparently I repacked only the old agent. If I run the client build from /usr/local/grr_build/ with the grr source code repository inside that folder, I should get an updated grr agent template under /usr/local/grr_build/grr/executables/linux/templates/ right? This is not happening right now. Could you please look into the build output that I had attached earlier. I thought it should end with a line that said something like "generated a zip file template..", similar to the windows build but I did not see anything like that. Maybe through that log you can tell me where the build process is not working properly. Thanks, Aditya |
|
From amoser@google.com on January 09, 2014 09:20:57 you should get a template in wherever ClientBuilder.template_path points to. It should give you this log line that you mention though, weird it's not there. What's the command line you used? just for reference, I used a probably pretty similar config and I got: |
|
From aditya.kichu on January 10, 2014 02:18:39 Andy, Based on the wiki ( https://code.google.com/p/grr/wiki/BuildingLinuxClient),here is the command that I used to build the client: PYTHONPATH=. python grr/client/client_build.py --config=grr/config/grr-server.yaml build I am not seeing anything like ClientBuilder.template_path in the yaml file. Here is what I have related to ClientBuilder in the grr-server.yaml file: ClientBuilder Context: ClientBuilder.executables_path: | Target:Linux: I want to know what this parameter is for in the yaml file: ClientBuilder.target_dir: | Another thing that I observed was that ClientBuilder.template_path has a default value inside lib/build.py. For the default case and the case where I manually add the following line into the yaml file, ClientBuilder.template_path: | I get the same output as shown in the log file before which stops at the line INFO: building COLLECT out00-COLLECT.toc. Whereas, when I intentionally give a wrong value to template_path like this: ClientBuilder.template_path: | I get the following error in the log: 8150 INFO: checking EXE This means that it goes to the last step of building the zip file. However, when the values are right it somehow does not produce anything. Another doubt that I have is whether lack of access previleges is preventing the creation of the template. If you look at my log file there is an error about permission being denied for /var/log/grr/GRRlog.txt Should this build command be run as root? I tried this but I get an error saying pyinstaller does not support building as root. Please advise on what I should try next. Thanks, Aditya |
|
From amoser@google.com on January 10, 2014 02:56:06 So it seems that since you are using a very old version of the build script, there is no log message. I think everything works as expected. Please confirm that the template path is what you are expecting, I suspect it writes the .zip somewhere but you are looking for it in the wrong place. To do this: PYTHONPATH=. python grr/client/client_build.py --config=grr/config/grr-server.yaml --config_help build that gives you a long output, look for ClientBuilder.template_path and check the * Value. |
|
From aditya.kichu on January 10, 2014 05:36:27 After looking at the output of the command you told me to run, I was really confused as the Configuration values I got were weird. Some of the values were empty and the template path was pointing to windows. However, I located the zip file template in /usr/share/. I knew that because I had the GRR server on the same machine some of the config that was used was messed up. So I quickly moved the code to another VM and there the zip file was created as expected in /usr/local/grr_build/grr/executables/linux/templates/ Now I have an issue which was not there before. The repacking of the agent is throwing an error. Please see the screenshot below. When I checked the value of ClientBuilder.target_dir it was empty. Is this the reason for the problem? Thanks, Aditya Attachment: repack_error.png |
|
From aditya.kichu on January 13, 2014 04:28:44 Please find the output of the client build command with the --config_help option attached. In the file attached the ClientBuilder.template_path points to windows. Do we need to remove the windows related entries in the grr-server.yaml file for linux builds? or is this some problem with my config? Thanks, Aditya Attachment: config--help_output.txt |
|
From amoser@google.com on January 14, 2014 05:26:50 It looks a bit like something is wrong in your config. if you run the --config_help it should show you the Linux versions of all the config options (you are running this on Linux, right? :)) The --platform and --arch parameters are only used later to switch the config. You can have multiple platform configs in one config file: It seems like your config leaks the windows specific options into the main ones? Also, I think the error you get in the screenshot is that you try to execute something that is not present on your system? Maybe that's a config error too, hard to tell. What are the exact commands you tried to run? |
|
From aditya.kichu on January 14, 2014 06:02:40 Andy, Yes. I am running it on linux only :) For getting config-help I ran the command as you had mentioned: With regards to the error in the screenshot, I ran grr_config_updater repack_clients. With the old linux client, it used to repack properly and I used to have linux clients working. It is not working with the new client deb (which I am not sure has been built properly). Even I do not understand how it always picks windows related parameters. I have attached the config file that I am using as a reference. Thanks, Aditya Attachment: grr-server.yaml |
|
From amoser@google.com on January 14, 2014 06:35:19 I have no idea what's wrong but some quick notes. Your config is probably fine, I used it to repack 2.9.2.0 clients (after adjusting the version in the file you posted). I didn't try them but I don't get the error you see. Repacking takes a template, usually a .zip from /usr/share/grr/executables/linux/templates/, and builds a .deb from it. So you need to get you .zip working, the .debs do not really matter. Apart from that I can't really tell what's wrong, sorry. I can say that the 2.9 server works nicely, any change you can port your local modifications to it? |
|
From aditya.kichu on January 14, 2014 07:49:19 Andy, Based on your previous post, I looked at the source code and found that in client_actions/admin.py, Client.platform was initialized to windows and this did not change at all and hence the problem. I fixed that and then ran the client build with config-help now it shows platform as linux. However, still the repack does not work as I believe that some more entries need to corrected in the build input in the source code. Thanks, Aditya |
|
From aditya.kichu on January 14, 2014 09:05:46 Hello, I figured out that the reason for the packing error is that in the deb inside the RULES file, that are some calls like dh_link and dh_makeshlibs, which require the value of ClientBuilder.target_dir which in turn requires the value of Pyinstaller.output_version_dir and this value is currently empty in the output of config-help. Should the config_help output reflect the values after including the definitions in the yaml file also or does it reflect the default values? It seems to me like the values in config_help output are getting updated only if I change the default values in the code and not in the yaml file. Along the same reasoning, even though Pyinstaller.output_version_dir has in the yaml file but the config_help output lists the following:
There is correspondingly no code entry which initializes Pyinstaller.output_version_dir which explains the null value. I am thinking of trying to create a new default config_lib entry in code to see if this gets updated. But I am not sure if this is the right way to do it. Please advise. |
|
From amoser@google.com on January 14, 2014 09:42:12 All changes you do to output_version_dir will be ignored since this parameter has been deprecated entirely. As you stated, if there is no code defining a config option, this will never get parsed. The target_dir option is also empty in my build but it is actually used. I think this might be a bug, not the one that you see here though. I will investigate. Can you maybe use pdb and step through the build process to see what exactly goes wrong? That would also enable you to check config option values right at the point where they are used. |
|
From aditya.kichu on January 15, 2014 04:49:15 Andy, I do not know where the code is supposed to read off the yaml file but it does not happen and a lot of parameters are '' causing this silent problem. I also found out that the size of the new client built is 13.2 MB, whereas the original client has a size of 26.3 MB. |
|
Aditya are you still seeing this with the current repo head and/or still working on this bug? If not we'll close it out. |
From aditya.kichu on January 08, 2014 08:33:38
What steps will reproduce the problem? 1. Built the linux client from source
2. Repacked it on the server and installed on linux client
3. Flows run on the linux client give runtime errors on new flows, works with existing flows. What is the expected output? What do you see instead? I have attached the output of the linux client build for reference. I want to confirm if the new client functionality has been included in the agent that is built. Also, I would like to know whether the agent has been properly built in the first place or not.
When I test the new flows that I created on this linux client, I see that the existing flows like Fingerprint File work properly without any errors, whereas the new flows that I added do not work properly even though they work perfectly in windows.
For example, I updated the Fingerprint files flow with fuzzy hashing, by adding new entries in the Fingerprint Tuple and updating my protobuf. However, when I run this flow it causes a Key error in the client action. Please see the error backtrace below.
Failed Fingerprint: message GrrStatus { backtrace : u'Traceback (most recent call last):\n File "/usr/local/grr_build/build/grr/out00-PYZ.pyz/grr.client.actions", line 127, in Execute\n File "/usr/local/grr_build/build/grr/out00-PYZ.pyz/grr.client.client_actions.file_fingerprint", line 47, in Run\nKeyError: 3\n' cpu_time_used : message CpuSeconds { system_cpu_time : 0.0 user_cpu_time : 0.0 } error_message : u'KeyError(3,): 3' network_bytes_sent : 384 status : GENERIC_ERROR }
The client side code for the Fingerprint File is the same as the original code except that there is one more hasher in the code that I have. This hasher is not recognized and causes the Key Error.
Another new flow that I created also does not run properly. How do I check whether the protobuf used in the client is the latest?
I am using GRR source code version 2.8.1.0 on Ubuntu 12.04 LTS.
It would be great if someone could help me in identifying the problem.
Thanks,
Aditya
Attachment: linux_client_build.txt
Original issue: http://code.google.com/p/grr/issues/detail?id=91
The text was updated successfully, but these errors were encountered: