I'm running a free version of KDB on my local machine and installed Developer to check if this is something I wanted to start using.
I created a workspace/repository with just a basic username/pwd connecting to it via localhost:port/ax/
However, as I was just checking things out, i.e. it was meant to be very temporary, I have now promptly forgotten my user’s password over the Christmas break. I know, capital mistake.
Is there a way to reset the password for the user I created or find it somehow? I know I can read the code files from the repository under developer/workspace//, but I had some things on my scratchpad that I'd like to keep and I'd prefer to avoid the copy and paste however benign.
KDB version: 3.6
Developer version: 1.5.1
Related
In testing an upgrade to our Postgres database, we've discovered that one of our oldest versioned migration files is no longer valid SQL. This isn't an issue for the production database which (of course) has those migrations already in the schema_history_table, but standing up any new sandboxes is now made impossible by this broken V file.
What's the best way to bring an old V file into the modern world without forever orphaning our production database?
Of the top of my head I can think of a few possible options.
Configure postgres to enable previous version compatibility. I'm no expert at this, but I think there are some options here.
Just modify the historic migration scripts to they now work with the new version. This will mean that you can't stand up old versions any longer, but does this matter to you? I think that you'll need to run flyway repair after you do this, as Flyway will detect that the files have been tampered with.
Create a parallel set of scripts, one for each version, putting them in different folders. Then use the flyway.locations option to specify different folders depending on the version of the target.
Is there any complete guid for install postfix admin rather than official install guid?
I tried to install postfix admin several times. But I couldn't. I tried with official installation text file and several online tutorials.
Installing PostfixAdmin is not very hard, in-fact it's very simple.
PostfixAdmin is basically just a Apache+PHP+MySQL setup.
The bigger problem I think users are experiencing is how to make Postfix actually use the database backend and to "understand" the data it gets from it - What they refer to as the integration part in their INSTALL.txt for PostfixAdmin.
Take a look at the Postfix integration documentation at their GitHub page.
https://github.com/postfixadmin/postfixadmin/blob/master/DOCUMENTS/POSTFIX_CONF.txt
There are no easy way to just copy-pasta aka spray-and-pray install a complete SMTP/Mail system. Also I would not recommend it as you would have a very hard time to debug problems in your setup later on - And trust me SMTP servers always have problems :)
But basically once you have installed PostfixAdmin and that part works (i.e you can log onto the page, navigate around postfixadmin and add domains and so on) then you move on to adding all the .cf files it needs in the postfix etc directory.
Again, use that file above as reference. Or even search for multiple guides on Google. You will see that more or less all of them are doing the same steps.
Once your postfix is setup to talk "mysql" you can start to debug the mail.log files for problems that will (again trust me they will) come up. That will typically be beginner mistakes like the .cf files are not looking up the right data in the tables or using wrong parameters for email vs domain or that postfix don't have mysql support enabled and so forth.
I'm working on setting up and migration of old sites to a new server from Dreamhost. I have 130 sites to migrate. 1 is successful. The version is: 1.12.1
The mods in the first site upgraded well. No problems. Have a procedure to migrate. That being said, the second site, as I followed my own documentation, fails when I try to access /admin/index.php
What I get is this below:
So, this is more informational than code... so please forgive me. I don't understand why CMS MADE SIMPLE is actually not simple.
That seems like an annoying issue. Forgive any repetition but here is what I would check:
that is is 100% functioning on existing server
correct php version 5.4.3+ (5.6+ recommended) on new server
that all files & database are copied fully & without errors
config.php settings are updated for new hosting & database
that .htaccess, php.ini/.user.ini settings are appropriate
check php error log
are there any additional modules installed that may require additional php modules
try more coffee or a nights sleep - both have helped me solve all sorts of issue in the past!
consider posting on CMSMS forum - will get a wider range of CMSMS users/experience and suggestions
Good luck
Chris
Not sure what process you are using. So presuming that the site was working correctly on existing hosting and that the new hosting meets recommended requirements, especially PHP version:
Export database
Zip/Compress all website files into a single file
Copy zipped file to new hosting
Create new database & user with full access
Unzip files and make sure that they are in the right location (probably website root)
CHMOD config.php to 0644 and edit database, username & password settings for new hosting, CHMOD back to 0444
Make sure .htaccess is using correct settings for new hosting
Login to admin and clear cache
Sorry that the instructions are so basic, but the process really is Simple.
Possible issues can occur if:
the PHP version is older than 5.4.3 (5.6+ recommended).
files copied individually using ftp and some are corrupted/not copied.
Apart from that it is pretty straight forward.
Hope it helps
I'm trying to develop a little toy PHP project, and the most convenient location to run it is on a shared host I happen to have for my ill-maintained blog. The problem with this is that I have no way to run Subversion on this shared host, nor do I even have SSH access to be able to access an external repository from the host. Had I been thinking straight a few months ago when the hosting was up for renewal, I probably should have paid a couple extra bucks to switch to something a bit better, but for now I can't justify throwing money at having a second host just for side projects.
This means that a working copy of my project would need to be checked out to my laptop, while the project itself would need to be uploaded to the shared host to run. My best option seems to be creating a virtual machine running Linux and developing everything from in there, but I know from past experience that the extra barrier that creates, small though it may be, is enough that it puts me off firing the VM up just to do a couple minutes work to make some minor change I just thought up. I'd much prefer to just be able to fire up my editor and get to work.
While I'd imagine I'm not the first to encounter such a problem, I haven't had much success finding a solution online. Perhaps there isn't one beyond the VM or "manual mirroring" options, but if there is I'd expect StackOverflow to be the place to find it.
Edit: There's some confusion, it seems, so let me attempt to clarify. The shared host here is basically my dev server, but it has no svn or ssh. In other words, I can svn checkout to my laptop, but I can't run that on my shared host. Similarly, I can run/test my code on the shared host, but I can't do that on my laptop (well, I technically could, but it's Windows, and I don't want to worry about Win-vs.-Linux differences with PHP, since I do want this to become public at some point, and it will certainly be Linux-based at that point).
You might consider writing a post-commit hook to automatically upload the code to your host, so that any time you commit a change, a script executes that:
Checks out a copy of the code into a temporary directory
Uploads that code via FTP (or whatever your preferred method is) to the shared host
Cleans up after itself, optionally informing you via e.g. email when the transfer is successful
Subversion makes enough information available to these scripts at runtime that you could get more sophisticated and opt only to upload the files that changed or alter behavior based on specific property changes, for instance, but for a small project the brute force "copy it all" approach should be fine.
I'm trying to customize the location of the user.config file. Currently it's stored with a hash and version number
%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\
I want to it be agnostic to the version of the application
%AppData%\[CompanyName]\[ProductName]\
Can this be done and how? What are the implications? Will the user lose their settings from the previous version after upgrading?
I wanted to add this quoted text as a reference for when i have this problem in the future. Supposedly you can instruct the ApplicationSettings infrastructure to copy settings from a previous version by calling Upgrade:
Properties.Settings.Value.Upgrade();
From Client Settings FAQ blog post: (archive)
Q: Why is there a version number in the user.config path? If I deploy a new version of my application, won't the user lose all the settings saved by the previous version?
A: There are couple of reasons why the
user.config path is version sensitive.
(1) To support side-by-side deployment
of different versions of an
application (you can do this with
Clickonce, for example). It is
possible for different version of the
application to have different settings
saved out.
(2) When you upgrade an
application, the settings class may
have been altered and may not be
compatible with what's saved out,
which can lead to problems.
However, we have made it easy to
upgrade settings from a previous
version of the application to the
latest. Simply call
ApplicationSettingsBase.Upgrade() and
it will retrieve settings from the
previous version that match the
current version of the class and store
them out in the current version's
user.config file. You also have the
option of overriding this behavior
either in your settings class or in
your provider implementation.
Q: Okay, but how do I know when to
call Upgrade?
A: Good question. In Clickonce, when
you install a new version of your
application, ApplicationSettingsBase
will detect it and automatically
upgrade settings for you at the point
settings are loaded. In non-Clickonce
cases, there is no automatic upgrade -
you have to call Upgrade yourself.
Here is one idea for determining when
to call Upgrade:
Have a boolean setting called
CallUpgrade and give it a default
value of true. When your app starts
up, you can do something like:
if (Properties.Settings.Value.CallUpgrade)
{
Properties.Settings.Value.Upgrade();
Properties.Settings.Value.CallUpgrade = false;
}
This will ensure that Upgrade() is
called only the first time the
application runs after a new version
is deployed.
i don't believe for a second that it could actually work - there's no way Microsoft would provide this ability, but the method is there just the same.
To answer the first question, you technically can put the file wherever you want, however you will have to code it yourself, as the default place the file goes to is the first of your two examples. (link to how to do it yourself)
As for the second question, it depends on how you deploy the application. If you deploy via a .msi, then there are two hashes in the properties of the setup project (that the msi is built from), the 'upgrade code' and the 'product code'. These determine how the msi can be installed, and if it upgrades, overwrites, or installs beside any other version of the same application.
For instance, if you have two versions of your software and they have different 'upgrade' codes, then to windows they are completely different pieces of software regardless of what the name is. However if the 'upgrade' code is the same, but the 'product' code is different then when you try to install the 2nd msi it will ask you if you want to upgrade, at which time it is supposed to copy the values from the old config to a new config. If both values are the same, and the version number didn't change then the new config will be in the same location as the old config, and it won't have to do anything. MSDN Documentation
ClickOnce is a little bit different, because its based more off of the ClickOnce version # and URL path, however I have found that as long as you continue to 'Publish' to the same location the new version of the application will continue to use the existing config. (link to how ClickOnce handles updates)
I also know there is a way to manually merge configs during the install of the msi using custom install scripts, but I don't remember the exact steps to do it... (see this link for how to do it with a web.config)
The user.config file is stored at
C:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<version>
<C:\Documents and Settings> is the user data directory, either non-roaming (Local Settings above) or roaming.
<username> is the user name.
<companyname> is the CompanyNameAttribute value, if available. Otherwise, ignore this element.
<appdomainname> is the AppDomain.CurrentDomain.FriendlyName. This usually defaults to the .exe name.
<eid> is the URL, StrongName, or Path, based on the evidence available to hash.
<hash> is a SHA1 hash of evidence gathered from the CurrentDomain, in the following order of preference:
1. StrongName
2. URL:
If neither of these is available, use the .exe path.
<version> is the AssemblyInfo's AssemblyVersionAttribute setting.
Full description is here http://msdn.microsoft.com/en-us/library/ms379611.aspx
(I'd add this as a comment to #Amr's answer, but I don't have enough rep to do that yet.)
The info in the MSDN article is very clear and appears to still apply. However it fails to mention that the SHA1 hash is written out base 32 encoded, rather than the more typical base 16.
I believe the algorithm being used is implemented in ToBase32StringSuitableForDirName, which can be found here in the Microsoft Reference Source.