1 2 Previous Next 16 Replies Latest reply on Aug 22, 2016 10:33 AM by Bill Robinson

    File Deploy Job Issue

    Yogeesh Kompa

      Dear All,

       

      While deploying files (file deploy job) from one unix server to multiple unix servers we are facing strange issue. The file is getting copied but the file ownership and permission is getting corrupted.

       

      Please find below screenshot of job's "Option" tab that I have selected.

       

       

       

       

      Could you please help what setting to use in deploy job to retain ownership and permission of files and folders or something I am missing here?

       

      Thanks in advance,

      Yogeesh

        • 1. Re: File Deploy Job Issue
          Bill Robinson

          corrupted how ?

          • 2. Re: File Deploy Job Issue
            Ashish Vijay

            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

            • 3. Re: File Deploy Job Issue
              Yogeesh Kompa

              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.

               

              Thanks,

              Yogeesh

              • 4. Re: File Deploy Job Issue
                Yogeesh Kompa

                Ashish Vijay

                 

                Also, as you suggested, I tried the option un-checking sync push and backup options and re-ran the job. But still the issue persist.

                 

                Thanks,

                Yogeesh

                • 5. Re: File Deploy Job Issue
                  Ashish Vijay

                  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

                  location.

                   

                  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

                  1 of 1 people found this helpful
                  • 6. Re: File Deploy Job Issue
                    Yogeesh Kompa

                    Thanks Ashish for the response.

                     

                    I will work on this and let you know the outcome.

                     

                    Thanks,

                    Yogeesh

                    • 7. Re: File Deploy Job Issue
                      Todd McDaniel

                      Yogeesh,

                       

                      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.

                      1 of 1 people found this helpful
                      • 8. Re: File Deploy Job Issue
                        Yogeesh Kompa

                        Thanks Todd for the response. Got your point.

                         

                         

                        Ashish Vijay

                        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.

                         

                        OR

                         

                        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.

                         

                        Thanks,

                        Yogeesh

                        • 9. Re: File Deploy Job Issue
                          Bill Robinson

                          if you keep the uid/gids in sync in your env between servers then you wouldn't have an issue.

                          1 of 1 people found this helpful
                          • 10. Re: File Deploy Job Issue
                            Yogeesh Kompa

                            Hi Bill,

                             

                            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.

                             

                            Regards,

                            Yogeesh

                            • 11. Re: File Deploy Job Issue
                              Todd McDaniel

                              Yogeesh,

                               

                              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.

                              • 12. Re: File Deploy Job Issue
                                Bill Robinson

                                "Any admin running a deploy or any other job, should have an account on every server they are managing from BSA."

                                why ?

                                 

                                what is that a 'serious issue' ?

                                • 13. Re: File Deploy Job Issue
                                  Todd McDaniel

                                  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.

                                  • 14. Re: File Deploy Job Issue
                                    Bill Robinson

                                    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.

                                    1 2 Previous Next