Custom Query (1145 matches)


Show under each result:

Results (106 - 108 of 1145)

Ticket Resolution Summary Owner Reporter
#1442 duplicate syncupdate has no reason to exist achernya

Reported by achernya, 10 years ago.


We have journaling filesystems now, and apt-rdepends indicates it I a dependency of clients and nothing else.

#1444 duplicate See if we can finally get rid of the pam/schroot hack in reactivate jdreed

Reported by jdreed, 10 years ago.


In snapshot-run, we write out KRB5CCNAME to a file to be parsed by pam_env. Comments in snapshot-run say we only needed that until pam-afs-session 2.4. We tried removing it for the Precise release (in 362cef) and had to added it back (59af91). We should see if Trusty will let us kill it once and for all.

#1508 duplicate File OpenAFS bug about apparmor jdreed

Reported by jdreed, 9 years ago.


In some cases, apparmor is convinced that a user process is directly accessing the OpenAFS cache, and prior to debathena-apparmor-config 1.2.9, would deny it. apparmor's denial causes OpenAFS to think the fileserver went down, and then it immediately comes back up, but parts of the user's homedirectory still give weird ENOENT/EACCES errors until an fs flushv.

Jul  7 10:08:36 jdreed-vmware-4 kernel: [   94.060284] audit_printk_skb: 66 call
backs suppressed
Jul  7 10:08:36 jdreed-vmware-4 kernel: [   94.060287] type=1400 audit(1404752916.705:92): apparmor="DENIED" operation="file_perm" profile="/usr/bin/evince" name="/var/cache/openafs/D3/V7476" pid=3192 comm="evince" requested_mask="r" denied_mask="r" fsuid=7263 ouid=0
Jul  7 10:08:36 jdreed-vmware-4 kernel: [   94.060384] afs: Lost contact with file server in cell (code -13) (all multi-homed ip addresses down for the server)
Jul  7 10:08:36 jdreed-vmware-4 kernel: [   94.060385] afs: Lost contact with file server in cell (code -13) (all multi-homed ip addresses down for the server)
Jul  7 10:08:37 jdreed-vmware-4 kernel: [   95.064175] afs: failed to store file (network problems)
Jul  7 10:08:41 jdreed-vmware-4 kernel: [   98.855523] afs: file server in cell is back up (code 0) (multi-homed address; other same-host interfaces may still be down)

Anders notes:

       OpenAFS should never be accessing /var/cache/openafs with the            
       credentials of a random user process.  However, there have been bugs     
       of that form before, and they tend to break SELinux and AppArmor.  We    
       should try to file it.

So somebody who understands AFS better than me and has free time should look into this and report the bug. This is consistently reproducible on stock Trusty, with login-graphical installed, and the stock upstream apparmor-config (which means uninstall apparmor-config, or use manual-config).

Note: See TracQuery for help on using queries.