8/14/2017 6:57:08 PM
PR #1325.
Instead of simply displaying an error message when assignUserDirOwnership fails, now it throws an Exception using the handleError method.
This is better because if the flow fails later due to unexpected permissions for the user then it would be hard to detect that the failure of assignUserDirOwnership is the root cause. Now the flow will fail quickly and be easier to diagnose.
|
8/11/2017 6:11:31 PM
now, Azkaban leverages the execute-as-user script so that users' jobs are run via a process of the user's creation instead of as the Azkaban process. This is really important because it restricts users from interfering with Azkaban or reading secure information that Azkaban holds.
While this script works well, it has a bug in which it doesn't remove the "azkaban" group from the users list of groups. This is not secure. It did have a side-effect though that should be kept: it allowed users to write to their /execution/<exec_id>/src directory. This is desired because it gives users the ability to cache temporary data on the executor between jobs in a flow.
This PR does two things:
It fixes the security bug in execute-as-user.c by calling the initgroups() function for the effective user.
It uses the execute-as-user executable to set up the /execution/<exec_id>/src directory so that its permissions allow the user to work within it . It also makes sure that this is done in a way that can be cleaned up later by the Azkaban thread. It does this by executing the command: chown <user>:azkaban
This particular change will be hard to test with unit testing, but it will easy to test within the integration testing suite (I discussed this with @jamiesjc). It can be done completely with two test:
The first one tries to write to the current working directory. If the flow concludes successfully (i.e. the file is successfully created), the test passes.
The second tries to perform an "improper" action reserved for members of the "azkaban" group. If the flow fails (i.e. the action cannot be performed), the test passes.
Together I believe this will give sufficient test coverage for this part of the code and each test should be quick (one job flows that should terminate in < 1 second)
|
8/11/2017 4:33:11 PM
plugin
2. make duplicate log construction logic an util method
|
8/11/2017 11:22:08 AM
delete API based on a key. The key is the relative path of the project file and is stored as `resourceId` in the DB.
|
8/10/2017 9:43:54 PM
ExecutorManager class (#1324)
|
8/10/2017 8:04:13 PM
trigger (#1328)
Previously TriggerManager won't persist updated schedule when schedule gets updated(e.x. add new SLA rule to a schedule). It gets persisted only when schedule gets triggered. So if we add a SLA rule to a schedule or do a reschedule, and restart the web server after it, these updates will be lost.
|
|
|
8/10/2017 4:52:15 PM
instance. (#1320)
Current features:
- version
- used Memory
- Max memory: XMX value
- Database availability: SELECT 1 check
- Map of current executors
Example:
```
{ "version": "3.33.0-11-g1ac90f03", "installationPath": "/full/path/to/azkaban-solo-server/lib/azkaban-web-server-3.33.0-11-g1ac90f03.jar", "usedMemory": 65144664, "xmx": 3817865216, "isDatabaseUp": true, "executorStatusMap": { "104": { "id": 104, "host": "abc.def.company.com", "port": 15462, "isActive": true } }
}
```
|
8/9/2017 9:40:47 PM
log looks like this:
Starting job 1 attempt 1 at 1502324648910
it makes people misinterpret this as the 1st attempt of running the job, this PR changes the message:
Starting job 1 retry 1 at 1502324648910
|
8/9/2017 5:13:59 PM
related to this class and I don't want to make a PR with both changes, so sending off a quick PR for just running the SaveAction command on the ProcessJob class first.
|
