We are using confluence 5.8.5 server version for our internally small teams in my company.But, we got an order to move our confluence to enterprise-confluence handled by another large confluence admin team in our company. So, I thought the best way is to just export each space to xml and import in the enterprise one. I tried to export one space and I got below error.
There was an error in the export. Please check your log files. :java.io.IOException: No space left on device
I observed that I do not have space in my confluence 5.8.5 in "/var" mount. I raised request to increase space which may take 3 business days. As a workaround is there any way I can export the space to any other mount or just directly from UI to my desktop like we do for jira?
Exporting and importing Space in Confluence needs free storage space in the Server. Other than that, exporting/importing space and site requires free memory as well so please ensure that you allocated enough memory to JVM. I believe you have to wait for extra storage at this stage.
Also,practically importing to next major version is not a good practice for Confluence. I would try it in a test environment prior to importing directly to production.
Related
I am having some recent problems with TFS 2018 that have escaped my ability to troubleshoot. The application runs on a Hyper-V VM hosting Server 2019 and connects to a separate MS SQL 2016 database over on a separate Windows 2019 VM.
A few weeks ago we migrated our database server over to a new machine which, over the course of setting our existing TFS server up to use the new database, required us to run though the TFS setup wizard again.
Everything was fine for about a week when we started to have issues, specifically with the TFS web front-end we use. First we lost various icons on the webpage, with the browsers (Chrome, Firefox, etc). replacing them with rectangles:
A little while after that we lost our project Dashboards, and the whole dashboard page is just blank now. A little while after that, our WIP build/test automation feature also lost its management section of the site.
Other than these things not displaying, things generally "work" - the source control stuff functions, work items can be interacted with, etc. It's just that the interface is clumsier without the icons (which extends to every icon within every work item type, not just the banner I shared) and we can't get our automated test reports without the site's front-end for it. The latter is the real show stopper.
I spent some time troubleshooting and at best was able to figure out a maybe solution for the icon problem: https://social.msdn.microsoft.com/Forums/en-US/c1038468-9d94-473d-a020-254789e9a19b/tfs-2015-update-2-missing-icons?forum=tfsgeneral
This seemed to do the trick for just the icon problem, though some time later they disappeared and reappeared when people were refreshing pages. I'm still unsure if the re-failure was a fluke or not, as we rolled back the VM snapshot the changes were made on shortly after.
Using Chrome's developer tools, it seems like the lack of dashboard data is related to issues retrieving content on the host server for a cause we cannot determine.
Here is what shows up on the DevTool in Chrome for our main project's Dashboard:
What's interesting is the error claims widget.css is either not present or empty. Neither of these are the case as I can find the file and read data in it.
I recognize MIME types as a thing that shows up in IIS but I don't know what to do with the information. Should I be adding .css to the MIME Types list within IIS? Maybe that was set and the wizard reverted it?
Here's what shows up in the Builds section:
Thing is, I don't know what to do with this information. I found some vague hints online from people having similar issues with sites they were themselves coding (which stated the errors in question were red herrings), but this TFS front end is not something I've created and I had not any idea what to do with the information shared.
Does anyone have an idea of what might have gone wrong with the dashboards here? I have run out of ideas and can't figure out a different attack angle to approach this from.
We've got an issue with SharePoint where we keep running out of space on our Team Drive. We know why, it’s because with versioning turned on all changes are stored and with some of our larger files (e.g. MS Access databases) that can quickly add up.
What I need is a way to either add some columns to show a count of the number of versions a file has and the size of the sum of those versions, so I can then sort and find the offending files quickly. Or are there any other solutions to quickly track down which files are adding bloat due to versioning? Powershell? I should add that I don't have network admin, only local admin on the machine.
This is the interface I'm working with, there are obviously files within each folder that these columns would reference:
This would require to write custom code to update as report.Please refer for more details to update according to your requirement.
https://www.sharepointdiary.com/2013/01/document-versions-size-report-powershell.html
Short version: see topic
Detailed version:
I want to use a specific 3rd party theme for Windows. I'm already using an open source solution which I've compiled myself to disable Window's restriction on Themes.
In the past, when using 3rd party theme related mods that come with DLLs (for example authui.dll for the login ui, or imageres.dll for modding system icons), I avoid using unknown DLLs by simply copying the unknown DLL's theme related resources (such as Bitmaps, Icon groups or UI scripts) unto it's virgin MS Dll counterpart. I call this resource grafting, where resource are changed but the executable elements of DLLs or exes are left alone.
Going back to the theme I want to install, I used sha256 hashing to determine that only aero.msstyles which is also modifiable by resource hacker. So I did the same thing I usually do and transferred resources from the third party theme to Window's own aero.msstyles. Problem is that I ran into a type of resource that I am unable to read or know the contents of. It's called VARIANT. From some experiments done in a VM, it seems to be some kind of binary UI script that resource hacker is unable to decompile. I usually like to be able to read any UI scripts that I transfer but I am unable to do so with this one.
Would this constitute any real security risks? Can UI scripts be side-loaded with some kind of exploit? Seems unlikely to me since the function of a theme file (msstyle) is to coordinate the appearance of the system UI but I don't know enough about the inner working of the whole theming system to be sure. I thought I'd get some other point of views before I take the theme out of the Virtual Machine.
I used vBinDiff to compare the hex code the altered VARIANT/NORMAL binary to that of the original theme. You can also copy the binhexes and save them to two text files which you would compare with WinMerge.
vBinDiff and WinMerge will highlight what modifications and what additions/substractions were made to the binaries, displaying them side by side. I read through the differences, 90% of them were no larger than 4 octals (4bytes), typically what you would expect to see when modding colors using a hex editor. The biggest divergence was an added 32bytes of code.
There are two possible explanations for the such an addition: (1) the author added extra image resources and added the entries necessary to reference them, (2) there is some kind of unwanted code that has been slipped in.
To address the possibility of 2, I did a search to see how small trojan code can get. How likely is it that a trojan has been stuffed into 32bytes if compiled UI scripts? I found a few mentions of an old 17byte virus from the DOS era called trivial which I disegarded right away because it would become apparent very quickly given it's known behavior. As far as full fledged trojans with backdoor and downloading abilities, the smallest I found was 20kb (trojan tinba), discovered in 2012. There is also Catchy32 which is still considered a Trojan but with simpler and very specific functionalities and that one's about 580 bytes (reference). Based on this info, I established that it is highly unlikely (if not impossible) to slip any code in 32bytes of code and established that the resource in question is clean.
Mind you, this doesn't answer the question I asked (can binary UI script resources in a theme carry mal-code) but it does solve my dilemma. Thought I'd share it.
I have an issue in updating contents in Umbraco. Whenever I update something in Umbraco, I have to wait at least one hour, sometimes 12 hours to see the changes at front-end.
The only way to see the changes immediately at front-end is "empty the connection string value umbracoDbDSN and refresh the page, then put the connection string back and refresh the page". I have to do everything I update something in CMS.
Do you guys have any idea what is happening here? Thanks.
The problem was. Umbraco was configured to run on load balanced servers on our old servers. I had to turn it off on the new server.
<distributedCall enable="false"> in umbracoSettings.config
What version are you running? When v5 first came out, I had a big problem with that (and solved it like you by touching the web.config to force a reset. Hopefully you are not using v5 (as its been discontinued and has extreme performance issues).
I have not had that problem in any v4.x versions that I can remember; changes should show up instantly after you republish.
Are you running in a standard configuration? Using a webfarm by anyt chance?
Is the ~/App_Data/umbraco.config file being written to on publish? This is the XML cache file that is used in displaying you website.
When you publish a node, the data is serialized into XML, stored in a database table and then written out to the umbraco.config cache.
This could be some kind of permissions issue, if umbraco doesn't have rights to read/write the file. Or you could have a corrupt dll that just isn't writing to it correctly. Or perhaps it's writing it out just fine, but your server is caching you pages in a weird way. Either way, I'd take a look first at the umbraco.config and make sure the data is being written to it on publish.
Is there some way to optimize the Netbeans IDE for PHP (and Symfony)? It's very good with code hinting, debugging etc, but the downside is that while writing code, the disk works intensively all the time which is disturbing and besides the editor slows down slightly because of the code hinting. I have 8GB memory, so it would be quite sufficient for all Netbeans needs. I mean, is it possible to somehow limit the disk usage but without limiting the code hinting? E,g, make it load all code hints to memory.
Here is a workaround which solves the problematic symptoms, i.e. the NetBeans editor now works without small delays from code hinting and the disk is quiet. I installed RAMDisk with 500MB capacity. Then I moved the .netbeans folder with user files to this RAMDisk, as described in wiki.netbeans.org/FaqWhatIsUserdir. Just FYI, moving the project folder itself made no difference, only .netbeans folder was necessary to move.
Try to deactivate the Local History plugin, maybe it is causing the high disk usage.
(Be careful if you don't have any vcs)
Although I've never have a problem with Netbeans and disk usage, maybe your disk is broke.
Kudos to #camcam for answering his own question and posting the RAM disk suggestion. In case there are other Mac users out there who want to do this on a Mac, here are instructions:
1) Create a 500MB RAM disk:
diskutil erasevolume HFS+ 'NetBeansRAMDisk' `hdiutil attach -nomount ram://1048576`
2) Locate the NetBeans application in the Finder, control-click on it and select "Show Package Contents"
3) Add this line to Contents/Resources/NetBeans/etc/netbeans.conf:
netbeans_default_cachedir="/Volumes/NetBeansRAMDisk"
(Note: the cachedir option was added in NetBeans 7.1.)
For more info, see:
http://bogner.sh/2012/12/os-x-create-a-ram-disk-the-easy-way/
http://wiki.netbeans.org/FaqAlternateUserdir
I have been using NetBeans since version 3.x I have never seen it access the disk all the time. I have regularly ~20 projects open with ~350.000 LOC
You should first make sure it's actually NetBeans that does the disk access (on Windows you can do this with ProcessExplorer, don't know about Linux).
If it's really NetBeans, you could try to give it more memory to cache more data in memory. See the NetBeans FAQ for details
And of course make sure your system is not swapping because you have too many programs open (even though it's very unlikely with 8GB RAM but not unseen...).
If you already configured NetBeans to use more memory, maybe you gave it too much and that's why the system is swapping (just a thought).
Is your project stored in Subversion? Do you use TortoiseSVN? With he default installation TortoiseSVN has a background process that caches information about the status of your versioned files. I have seen that scanning the whole harddisk in the background...