RPMs cannot be uninstalled

[nefilim]

[root@ip-10-0-20-131 target]# rpm -e supportconsole
Shutdown supportconsole
Redirecting to /bin/systemctl stop  supportconsole.service
Try deleting system user and group [supportconsole:supportconsole]
Deleting system user: supportconsole
/var/tmp/rpm-tmp.x55jfx: line 11: deleteUser: command not found
Deleting system group: supportconsole
/var/tmp/rpm-tmp.x55jfx: line 16: deleteGroup: command not found
warning: %postun(supportconsole-1.0.4-1.noarch) scriptlet failed, exit status 127
[root@ip-10-0-20-131 target]# deleteUser
bash: deleteUser: command not found

generated spec:

# Scriptlet syntax: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax
# $1 == 1 is upgrade and $1 == 0 is uninstall
if [[ $1 == 0 ]]
then
    echo "Try deleting system user and group [supportconsole:supportconsole]"
    if getent passwd | grep -q "^supportconsole:";
    then
        echo "Deleting system user: supportconsole"
        deleteUser supportconsole
    fi
    if getent group | grep -q "^supportconsole:" ;
    then
        echo "Deleting system group: supportconsole"
        deleteGroup supportconsole
    fi
fi

should be userdel and groupdel no? I did notice the linked Fedora docs aren't too excited about cleaning up users/groups:

https://fedoraproject.org/wiki/Packaging:UsersAndGroups?rd=Packaging/UsersAndGroups

Do not remove users or groups
We never remove users or groups created by packages. There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do with them?) and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups deleting the user/group might not be possible or/nor desirable (eg. when using a shared, remote user/group database). Cleanup of unused users/groups is left to the system administrators to take care of if they so desire.

[muuki88]

These functions are defined via the control-functions linux script replacement.
For linux see control-functions

Your rpm scriplets should contain these functions this means

1. A bug, as they are not inserted correctly. (Add more assertions in sysvinit-rpm and scriptlets-rpm
2. You customized your rpm scriptlets and don't append, but override and forgot to insert the ${{control-functions}} like in the postinst-template

While checking this, I see that it's option 1. The postun-template doesn't insert the control-functions.

[muuki88]

@nefilim can you try the fix branch in #439 ?

[nefilim]

thanks @muuki88, I gave it a quick try but running into some problems

[error] /home/centos/build/SupportConsole/project/Build.scala:8: value NativePackagerKeys is not a member of object com.typesafe.sbt.SbtNativePackager
[error] import com.typesafe.sbt.SbtNativePackager.NativePackagerKeys._
[error]                                           ^
[error] /home/centos/build/SupportConsole/project/Build.scala:29: not found: value deploymentSettings
[error]   lazy val myPackagerSettings = deploymentSettings ++ Seq(
[error]                                 ^
[error] /home/centos/build/SupportConsole/project/Build.scala:98: not found: value packageZipTarball
[error]     aetherArtifact <<= (tgzCoordinates, packageZipTarball in Universal, makePom in Compile, packagedArtifacts in Universal) map {

my build file was created against sbt-native-packager 0.8.0-RC2, is this branch based on 1.0.0?

[muuki88]

True. You can test this easily with

git checkout -t origin/0.8.x
git cherry-pick 141c075
sbt publishLocal

[nefilim]

thanks, looking good!

[root@ip-10-0-20-131 SupportConsole]# rpm -e supportconsole
Shutdown supportconsole
Redirecting to /bin/systemctl stop  supportconsole.service
Try deleting system user and group [supportconsole:supportconsole]
Deleting system user: supportconsole

i do notice that the directory skeleton is left behind (suspect this is a RPM thing):

[root@ip-10-0-20-131 SupportConsole]# find /usr/local/supportconsole/
/usr/local/supportconsole/
/usr/local/supportconsole/bin
/usr/local/supportconsole/lib
/usr/local/supportconsole/share
/usr/local/supportconsole/share/doc

btw, something else I struggled with are the file permissions, I do something like this in my build:

    // change perms on all
    linuxPackageMappings := {
      val mappings = linuxPackageMappings.value
      // Changing the group for all configs
      mappings.map { mapping =>
        mapping.copy(fileData = mapping.fileData.copy(user = name.value))
      }
    },

and in the spec file all the files have my user set, though once it's installed, majority of files are owned by root. I've resorted to

    rpmPost := Option(s"""chown -R ${daemonUser.value}:${daemonGroup.value} /usr/local/${name.value}
                         systemctl daemon-reload
                         systemctl start ${name.value}
    """),

[muuki88]

and in the spec file all the files have my user set, though once it's installed, majority of files are owned by root. I've resorted to

This is intentional. If you look at /usr/share you will recognize that everything is owned by root. However the runuser command doesn't work as expected. I'm not sure why and when this stopped. We'll have to investigate this a bit more. However the systemv and rhel based systems make it really hard to provide a generic bootloader solution :/