corrupted how ?
Apart from Bill question, If you will select Permission and Ownership options in Sync Push then it will not copy file, it will only update Permission and Ownership of file. So do not select these option if you want to copy file on Unix Servers without changing permission and Ownership.
Give a try and let me know
Thanks Bill Robinson and Ashish for your responses.
Corrupted in sense, the files do get copy but the owner/permissions get change.
I found few more interesting thing here. Suppose I am trying to copy a file which has owner 'X' with user ID = 250 to target server. The file gets copy to the target but,
1) If user(owner) X is not present on the target server, the file owner field shows 250.
2) If user(owner) X is present on the target server with different user ID lets say 255, the file owner still shows 250.
3) If user (owner) Y has user ID = 250 on the target server, then the file owner field shows as Y.
4) If both user (owners) X (uid= 255) and Y (uid=250) are present on the target server, then post copy the file owner field shows Y instead of X.
So is it compulsory to have same user with same uid on target server for a file deploy job? How to tackle this kind of situation. Please suggest.
1 of 1 people found this helpful
Can you try to select "TimeStamp Only" in Global Deploy Option on same screen at bottom. Do not select ALL option. It should solve your issue.
Preserve File Source Characteristics
All — Preserves all source file characteristics after the file is copied to the target location. Source file
characteristics include the file's time stamp, permissions, UID, and GID for UNIX targets. For Windows
targets, source file characteristics include time stamp and permissions. However, Windows repeaters
can only preserve the file's time stamp. No other source file characteristics are preserved if you are
deploying files via a Windows repeater.
Timestamp only — Preserves only the time stamp of the source file when it is copied to the target
Deletevexisting target file(s) before copy - If a file being deployed exists on target servers, the file is deleted before the job deploys a new copy of the file.
If you select this option and you select the Timestamp only option or you use a Windows repeater to deploy
files, the files that are copied to the target are not assigned the permissions of the source file. Instead, they are
assigned the permissions of the user that the agent is impersonating. For UNIX targets, the user is determined
through a call to the setuid command. For Windows targets, the user is determined either by Windows user
mapping or user privilege mapping
These three options are important to solve your problem
Thanks Ashish for the response.
I will work on this and let you know the outcome.
1 of 1 people found this helpful
From a purely unix perspective, if you copy a file from one unix host to another and the user does not exist, the system will assign the file owner based on the group membership or assign group number as the owner as you described the behaviour. This is a default action in Unix.
You will either need to change/add the proper user/group to the original server containing the file or add the desired user/group to all target boxes prior to deploying the file.
Thanks Todd for the response. Got your point.
I tried both.
1. Timestamp only :
As expected, files have been copied with timestamp preserved but file owner is made as "root" and owner group as "system" (becoz BBSA user is mapped to root?)
2. All :
Files got copied preserving their properties (including permissions). But as I said earlier if the owner doesn't exit with same uid, file will have owner whoever has that UID. (As Todd explained).
So all I can do here is include a post command in the job to change owner of the file accordingly.
Baseline solution for this particular issue:
Include a post command in the file system deploy job to change the desired owner of the file/s post copy.
As Todd mentioned, we will either need to change/add the proper user/group to the original server containing the file or add the desired user/group to all target boxes prior to deploying the file.
Please let me know for any correction on the above mentioned comments.
1 of 1 people found this helpful
if you keep the uid/gids in sync in your env between servers then you wouldn't have an issue.
That's true. But it depends on the platform team to maintain it. I have advised them to follow the uid/gid sync.
Thanks for the response.
Now that I've had time to think about this issue. I see one glaring problem with your environment and maybe you have as well.
It has always been a standard for my environments that you cannot run jobs against servers for which you have no local account. its a security violation for most organizations. Also, our BLAdmin application support team members do not run jobs on client servers unless you are also the owner of the server in question. We only run jobs on the client servers if they are specific to keeping BSA updated such as agent related jobs, server refreshes, inventory jobs and similar non-invasive jobs.
Any admin running a deploy or any other job, should have an account on every server they are managing from BSA. Assigning RBAC roles that allow access without having a local account is a serious issue that should be addressed. Essentially the rule of least privilege is being broken, that states the user should have no access beyond what is necessary to do their job. If these users are required to run jobs from BSA, they should have a local account.
I hope that is clearly stated.
"Any admin running a deploy or any other job, should have an account on every server they are managing from BSA."
what is that a 'serious issue' ?
It is a serious security hole for any organization for any user to have access to a server that they as an approved windows or unix admin don't manage. When I worked at a former company we supported over 80 clients who don't want unauthorized personnel running jobs non-trivial jobs against their servers. Accessing a server without proper authorization is grounds for termination for every job I've ever had.
I currently work for a federal client where its even much more of a serious breach of security, having unauthorized access to manage a server, again a dismissible offense and the possibility of being charged.
not having a local account doesn't mean you shouldn't have access to manage a box. in fact typically having local accounts on a system is a security finding... if you are able to affect change on a box you shouldn't have access to via bsa then rbac isn't setup properly.